"From a vendor perspective, Linux is very hard to support because there are so many different versions out there: do we have Eudora, do we have SUSE, do we have Turbo Max?"

A lot of software I have found just has a 'linux' version, that should just work regardless of what distibution you have. It doesn't seem harder to me to support linux than it is to support windows or macs.

But yeah, it usually isn't preinstalled, so to install it, you have to know how to create a bootable flash drive, and how to boot to it. While there are plenty of easy to follow tutorials about that, but those who just want it to work would say it's too complicated before even trying to look into it.
Also sometimes linux software hasn't got an installer, but requires you to copy-paste a few lines, which would also be 'too complicated'.

I just gave it a try.


I've made an 8*8 sprite for that monster that spews rocks at you (I believe it's called an octroc) in monochrome, and 3 and 4 shade greyscale.
You can find pretty much all sprites from Zelda games on google images, and then just use your favorite layer-supporting image editing program, copy-paste your reference pick and overlay it with a layer you use for your pixel art. That way, you can make sprites relatively quickly.


This is my attempt: (monochrome, 3 shades, 4 shades and reference respectively)

So, as you may have guessed it already from the above screenshot, I'm working on a collision detection library. It is mainly meant to be used with GLib, and I hope that it will make calculator-3D programming more user-friendly, especially for programmers with few or no experience with 3D programming.
It's not ready to be used for a game yet, as it only supports a few basic things. The basic engine is already working though, which makes it easy for me to add more into the engine.
I mainly want to say this so that double work can be avoided. Further updates when the engine will be almost game-ready will be posted in a different thread, since this is not an official part of GLib, to avoid highjacking this one.

Anyway, have a screenshot:

Oh. I'll try that then. Thanks!

Hi,


I started getting more active in programming axe lately, but there are a few things bugging me with the options I have to code it.
Currently, I program axe in wabbitemu, with a dumped ROM image. Unfortunately, programming this way is rather hard and slow, since I can't type fast in the emulator, I often have to scroll trough the catalog for some functions, not much of your code is visible, and there is no copy-paste. And on top of that, wabbitemu is rather unstable, which means that I regularly loose some of my work, even though I often take backups. (if you know a way to recover the information lost in such a crash (basically an error message saying "wabbitemu has stopped working"), please share)


I've also looked into some computer editors (tokenizers) for axe, but while they probably work great with basic, they don't seem to work well with axe, since all the ones I found also attempt to tokenize label/variable names with no way to stop that, which generates errors. I know that when you work on your own project, you can try to avoid giving your variables names in which the tokenizer can recougnize tokens, but when you use a library, it can take a long time to rename everything in the library that causes errors after tokenizing, especially if it's still WIP so you have to do that again after every update. And when you are making a library yourself, it's better to give your unctions straightforward and easy to remember names instead of awkward names to avoid them from getting tokenized.


So here comes my question: Does anyone know a better alternative to programming axe? (note that I can't just always program it on my calc) If so, please share.

Yeah most 64 games used scaled sprites for various objects like trees and sometimes even chars. This is why I think on the HP Prime, using the Triangle command to generate basic terrains or walls you wouldn't really need that much 3D rendering for the rest, although detecting if a sprite is in front of or behind a wall might be trickier.

Well, even the (normal) DS does this, and many older games on both computers and consoles also do this. This is mainly used for objects far away or in other cases where it isn't that visible though, but they do use it. Mario kart n64 and other games of that era just did this to a much higher extend than now though, since currently it's pretty much only used to render particle effects.

It seems to crash on the whoami command. Is that normal?

EDIT: stack trace:
o> whoami
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/telnetsrv/telnetsrvlib.py", line 992, in handle
    self.COMMANDS[cmd](params)
  File "./omnibbs.py", line 286, in command_whoami
    self.writeresponse(self.omnilogin['username'])
  File "build/bdist.linux-x86_64/egg/telnetsrv/telnetsrvlib.py", line 738, in writeresponse
    self.writeline(text)
  File "build/bdist.linux-x86_64/egg/telnetsrv/telnetsrvlib.py", line 746, in writeline
    self.write(text+chr(10))
TypeError: unsupported operand type(s) for +: 'instance' and 'str'


Plop, here the version that shouldn't cause problem.
If the issue still there, I guess that something is unexpected in your code, and I will need the source to spot it 

That did indeed fix it. Thanks.