So with the recent release of ndless for 3.6 I have chosen to aquire a TI-Nspire CX and do some programming.

To get a feeling for the platform I have further chosen to port some first person shooter from 1996 and in nspire_emu it runs pretty well. However on my OS 3.6 Nspire CX CAS it first did not run at all and once I removed all printfs it ran but was kind of slow compared to nspire_emu. So I have some questions ..

1. Does it matter if I try to printf to the console ( serial port ? ) and there is no receiver connected ? From my program failure it appears so but I rather have the printfs() in so I can debug using nspire_emu. Are there other pitfalls that do not occur in nspire_emu but do on real hardware that can cause something like this ?

2. Either my Nspire ( hardware revision M ) is slower than normal Nspires or nspire_emu is faster than the actual hardware. As with porting some game most time is spent adapting to the new platform ( read optimizing ) I am wondering if nspire_emu is even cycle accurate or if I can only rely on benchmarks run on the real hardware.

So this is all that is going around in my head now.. I'll try to attach some photo to show my current progress.


PS: To skip my introduction in the introduction board I am the guy that did that Delsgolf FPS for the TI-89 last year.

*edit* Changed Title

Are you using nGL for this, or some other libraries?

Are you using nGL for this, or some other libraries?

I am using the original WinQuake sources as released by id software without any additional libraries.

This looks very nice, especially with the diagonal parts of the walls/ceiling. Knowing the great work you did in Desgolf I can only assume that this Nspire FPS will be very solid.

Welcome to the forums by the way

Is that Quake?

My reaction exactly.
also.

This is looking awesome. Welcome to Omnimaga!

Ninja edit: Is that Quake?

Yes it is Quake. I kind of overestimated the speed of the Nspire CX though so it will never run really fast i guess. TI calculators do not seem to follow Moore's law.

Wow that's epic.

Also the game welcome to Omni !

-- Development Update --

Although I have run my fair share of tests it would be cool if some other people can test it and report any errors found. Like graphical errors or crashes.

So if someone wants to test it here is a current build + sources. You need a CX to run, non-color nspire wont work.

In addition to the quake binary for the nspire you need at least the shareware data file pak0.pak. This is kind of hard to get when not running MS-DOS and one wants to honor the license so I deliver instructions:

-- Begin of Instructions of how to get the Shareware pak0.pak --

Get the quake shareware release quake106.zip somewhere of the internet.
One place is here: ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/quake106.zip

Inside the quake106.zip is a file called resource.1 - Extract it and rename it to resource.x

Get the LHa compression/uncompression utility. For Unix ask your packet manager. On windows this is somewhat hard but you can get a binary release here: http://gnuwin32.sourceforge.net/packages/lha.htm ( Binaries, the lha.exe inside the .zip is in /bin ). I read somewhere that the japanese Windows 7 gets it as an addon for the file explorer so you can also try that.

Move resource.x to a temporary directory and extract it. On windows you can do this with "lha x resource.x" if you moved lha.exe to the same temporary folder or lha.exe is in your $PATH. This hopefully creates a lot of obsolete files and a directory called "id1" which contains "pak0.pak"

You can also get Quake off Steam or so I heard.

-- End Of Instruction of how to get the Shareware pak0.pak --

MD5 Sums of the quake data files
pak0.pak 5906e5998fc3d896ddaf5e6a62e03abb
pak1.pak d76b3e5678f0b64ac74ce5e340e6a685 ( registered version )

On the calculator you need a directory structure like so:

quake/nquake.tns
quake/id1/pak0.pak.tns
quake/id1/pak1.pak.tns ( optional, if you bought Quake and got the pak1.pak file of the registered version put it there )


Then run nquake.tns