First of all, many thanks to Omnimaga for this spiffy new subforum!

In other news, the new release won't be out yet, but rest assured, I am working on it; However, I've hit some strange crashes and it's generally taking longer than it should.

If freezes on the "Loading" screen when I run it using the clickpad.  I have to pull the keypad and pull a battery to get it to go back to normal.  Its been a little while since I tested it, as I have not used my Nspire much, but when I get a chance, I will test it again!

Looking at the input code, I've found the ESC key was mapped to both right strafe and exit on the Clickpad . Since there's a crash on exit, that might've been it.
Unfortunately, it could also be related to some other strange issue. What OS are you using, by the way? I've only ran this on 2.0.1 CAS and 2.1 CAS (I don't have access to any other Nspires).

I've managed to fix all the originally-alloca statements (the memory wasn't getting freed due to an extremely embarassing bug...), checked that every malloc() has an equivalent free() statement and that all files are getting closed, but the crash-on-exit still remains.
Although now, it's giving me an unaligned_write_word error instead of an invalid processor mode. I don't think that's particularly helpful, though.

Except for unfreed memory and open files, are there any other things that might be causing a crash on exit? As you might have guessed from looking on my code, I'm not very good at this C thing (give me assembly or python any time!).

SirCmpwn, I was thinking of something like that myself, after I've finished working on this, but you obviously outran me. Good job! Better contrast and stuff is always nice.

Omnimaga, I made sure to steer clear of any legal troubles by only distributing the demo version, and not the full game. I might be largely ignorant of licences and legality usually, but this one thing I did check.

One small issue:  When using the clickpad hardware, I can't get the game to load, but when I switch to the touchpad, everything works fine.

Hmm, that's not a small issue, that's huge! Does it freeze the calculator? Reset once you run it? Or just not run at all? I've never encountered anything like that, but then again I don't have a Clickpad...

I've been playtesting it along with friends in school (only at lunches and free periods, I swear! ), and the most important features that are still missing are the map and save/load game support. I'll work on them this weekend.

Sorry again for only replying on weekends.

Still no progress, I am afraid. Mostly, I've just been lazy and trying to enjoy the last few days of holidays to their fullest...

You also get crashes on exit:
- if you haven't freed all allocated spaces
- if you haven't closed all open files

Hmm, I do close the wad file, but I am worried about freeing all allocated spaces... I think I've missed a few here and there. I just want to make sure, that refers only to the spaces claimed by malloc() and realloc(), right? Not every single variable and array there is, I hope, since that would be insane.

So may be there is a wrong address for a 2.0 CAS syscall, I'll try to find it. Tell me if you happen to have an idea on which one it could be.

My only idea was the free() call, after which the application always crashes, but you already checked that, so no ideas, sorry.

Are you sure ndless 2.0 progs work on 1.7? I just get a reboot when I run ndoom.

Just a reboot? No error message, no screen full of garbage, just a reboot immediately after running the executable? I've never had that happen with the current releases, there was always at least an error (not counting the crash-on-exit, that is). What OS/keypad/CAS you have?

Mrakoplaz: I understand how you feel about svn... until I lost 3 months worth of code, recovered half of it, then broke it once again, without the possibility to revert 3 days of (bad) work. However I'm not here to force anyone to do anything, so that's fine.

Just to say that I don't either use svn for shared projects, but the dumb way, as a cheap incremental backup with log messages. svn with more than 1 developer is a mess as soon as 2 people change the same file (half joke - but svn branches really sucks), and git seems nice but is too complicated for me. but the backup side of svn is nice. again, just my 2 cents, I totally respect your freedom.

Hey, if something like that happened to me, I'd probably love it too
However, I am ridiculously over-organized, and set up incremental backups on several external/USB drives, all of them labelled and such. I'd guess a SVN would make it a bit easier, but I have batch files and don't need the internet for my method (my connection is a bit... unreliable, let's say).

Since it accepts .wad files, I'll have to try this with Chex Quest

Unfortunately, I don't think it's strictly compatible. It might be, but I think Chex Quest had a few minor executable changes which could make a big difference. Did Ultimate Doom (the source for this port) work with a chex quest wad file?
Also, although the compatibility for any wad file is there theoretically, practically it's only been tested with the Doom 1 demo, so I have no idea if it will actually work at this stage (I'll start testing it with other wad files once the demo is fully playable, though!).

Yes, the clickpad controls are horrible. They would be a lot better if:
1) The left and right keys would rotate the display instead of strafing
2) Use Esc and Home keys for strafing

Ah, thanks for your suggestion! I had no idea where to put the two strafe keys, and didn't even for a second think of using those giant esc/home buttons staring me in the face...
I'll put in the next release, which I'll release when I fix the rendering in level 2. If you're desperate enough, the input code is in i_system.c and quite understandable (even though it's a fairly clumsy hack of fitting asynchronous events into a synchronous system).

Also, cheers everyone, for your great feedback. I know I say this every post, but I do genuinely mean it each and every time!

I've been looking into the crash-on-quit bug and it's driving me crazy. It always seems to crash after main() returns, which might indicate a fault with Ndless, but no other programs (that I know of) crash on exit, making it obvious that the problem is related to Doom in some way. Problem is, in what way? I've been looking at the Ndless sources, but still don't understand most of them, especially the assembly bits, so I can't really help there, sorry.

It might be related (or not) to what Mrakoplaz has reported previously, but I've got something interesting.
mViewer is quite stable with Ndless 1.7, on non-CAS calculators, or even with Ndless 2.0 on non-CAS calculators.
I've got problems with the same binaries with Ndless 2.0 on a CAS ClickPad.
After exiting mViewer, the calculator does freeze or reboot very often (which does not happen on the non-CAS).

Now that is interesting. Could it be to do with the sheer amounts of memory required by the programs? I mean, mViewer can load quite large .bmps and similar, can it not? Whereas Doom allocates more than six megabytes to itself...
Also, it crashes on my Touchpad 100% of the time as well, so it's not related to you using a Clickpad.

And sorry about the file uploads restriction, this was to protect the forums from spambots that uploaded adult material.

Hey, most forums don't let you upload files at all, so I view this more as a bonus than a limitation.

What formula are you using to convert the colos into grayscale?
Ive used 5/16 green and 3/16 for red and blue.

I've used the dumb-dumb idiot formula - take screenshot of game palette, load it into picture editor, click "make grayscale" button, select the "colour picker" tool, hover mouse over each field of the palette, type result into array. One of the dumber things I've done, but hey, it was the first time doing something like this, and it seemed to work

Quote

Actually, for all the Nspire stuff, it would be ideal to have an svn host dedicated to hosting Nspire. Such as someone here setting up their webserver for that.

What would you think of this? http://nspforge.unsads.com/

Sounds like a good idea, but unfortunately I absolutely despise all sorts of version control, from SVN to Git (Git more than the others, though). I agree they are critical for team projects, and that the only reason I don't like them is because I don't understand them... but that doesn't change the fact I hate them. I do backups manually, I track bugs with one .txt file, and progress/goals with a second one (whee! I am not even in university and already old-fashioned!).
Since they are very useful for about everyone else, however, good work! This will probably make it easier for others to start/track development.

To everyone else, I'm sorry but there's been no progress - I've been trying to track down the rendering issues in level two as well as the crash on exit, but found nothing so far. Also, further progress will slow down as holidays are ending. Hopefully though, nDoom will be in an acceptable state soon - apart from the rendering issues of level 2 and incomplete interface, it seems relatively playable.
I must point out though, my thanks to everyone for such encouraging feedback! I am not sure I'd be willing to spend twelve hours tracking down rendering bugs if it wasn't for this welcoming community; Since I only have an Nspire (and no TI84 keyboard), I can't really try many of your projects (and I've seen some really epic ones here, especially considering the relative simplicity of the hardware!), for which I apologize. Yet, this community has been so welcoming that I feel obligated to stay and somehow repay that... don't worry, I'll figure something out.

Also, while playing on the real calculator, I've noticed how the blurry display forces a very different playstyle on you; Instead of the good ol' run-and-gun of the original, you instead are slowly advancing, checking behind each corner, darting from cover to cover, etc. Interesting how the hardware changes things so much.

PS: Anyone tried the Clickpad controls? Are they absolutely horrible, or just subpar? Since I don't have one, I was working off a blurry picture of the keypad and couldn't do any practical tests.

The second one isn't due to Ndless, in fact, the Esc key doesn't exit the game, but brings up the main menu. But it isn't working yet, so it just crashes instead...

Actually, it shouldn't any more - I've changed it to call I_Quit() and end the game normally. However, there's a bug with that function. I always get the following message on the emulator:

Error at PC=FFFFFFFE: J mode is not implemented

And I am not quite sure what to do with that.
The error message also calls I_Quit() after displaying the textbox, so all these crashes are caused by the exact same thing.

First of all:

EDIT: also, do you think distributing Ndless 2.0 with it is a good idea? I mean, it's getting updating very often, so you won't be giving the latest version...

And this distribution of Ndless doesn't comply with the Mozilla Public License, both for version 1.7 and 2.0, so it's a problem for me.

Oh shit, I am such a noob! Messing up on something like that... I disabled the first download link, and this new one doesn't have Ndless in it. I hope you'll forgive me this one time, I'll make sure it doesn't happen again. Again, really sorry.

Anyhow, I've managed to finally fix the textures bug. The game is slowly getting into a state one might consider trying out.
GIF hyperlinked for those with low bandwidth:
http://img146.imageshack.us/img146/2302/10005.gif

Download:
http://www.box.net/shared/8ryc3coo68

There are two major problems with this build: One, level transition is broken, so you can only play the first level. And two, it's too dark... to fix this, just imagine you're playing Doom 3 instead

I see you have fixed the .TNS issue...

Yes, and I forgot to announce it was you found the problem. Many thanks for that, it was getting quite annoying...


Critor, thanks for cross-posting this over at tibank. I can read French, but nothing more so I'm afraid I won't be joining that community
Just one thing, I seriously wouldn't call nDoom anything like "beta"... more like pre-pre-alpha, at least in this state. Could you upload this new version as well?

Oh, and apologies to the community in general for not contributing to other topics and only replying here... it's a personal flaw of mine, when I decide on a project I concentrate 100% on that and ignore everything else until it's at least partly functional... just one or two further releases of this (level transition, screen brightness, menu), and I'll start looking at other things, promise! The remaining stuff should be pretty easy and shouldn't take too long, actually, at least compared to the textures bug which was driving me crazy (a three byte offset! three bytes, and so much suffering! aaaargh).
Well, that, and I still haven't quite switched from lurker mode yet...

PS: One (more? last?) apology to Goplat... it was not his emulator that was failing in the file transfer, it was my stupidity. Even 4MB files get transferred perfectly. Sorry!

Hmm, a post full of apologies... let's hope this trend doesn't continue.

Wow, I thought the initial response was amazing, but people seem to like the gif even more
Thanks everyone, for your kind words!

For the people who asked about FPS, it is... somewhat strange. The movement/turning is really smooth, so is the lighting, even with 8 monsters at once shooting at you (and yes, this is on my real Nspire - CAS 2.0.1). However, the guns reload/fire about two times slower on the calculator than on the PC, which makes the game feel slow even though the movement is perfect. I'm guessing this is yet another bug, but I'll only investigate after I've fixed the big things. I am not sure, but I think the monsters still fire at the same rate, making the game almost impossible (at least for me!).
Needless to say, since the walking is so smooth, I don't think FPS will be a problem.

What could be a problem, however, is the display. Right now, the constrast is so bad on a real calculator that it is almost unplayable (you have problems even under a lamp!). At first, I thought it was because of the LCD (and the movement blur), but the contrast is equally horrible whether there's a million things all moving on the screen, or you're staring at a wall. Furthermore, running it with an inverted palette, the game is playable (but horribly confusing!). So I'm really hoping this is just a stupid palette bug, and not a limitation of the display.
As for the LCD blur itself... it's better than you'd expect (i.e. stuff is still visible while moving), but I really have to fix the low contrast in non-inverted mode. We'll see how it is after I've fiddled with it.

About the textures: I think the renderer is working perfectly, but the WAD loader is feeding it garbage data... if you consider that there's no distortion from any distance/angle, I think it's safe to rule out the renderer. There's another problem on a real calc, that it only seems to open the WAD file 30% of the time (on the emulator, it's about 95%). I'll work a bit on that, but debugging it is hard since it's pretty rare when emulated.

ExtendeD: I'll give a full report on what did/didn't work, as well as some test cases, after I fix the big bugs here and release the first somewhat playable version. One thing I must ask though, did anyone test the free() syscall on the CAS 2.0.1? It appears to crash the calc every time I call it, no matter if I'm freeing one byte or a thousand. Because of this, there's currently a memory leak of about 100kb each time you load a level...

PS: I almost forgot! I must apologize to Goplat and his amazing emulator, for not thanking him in the first post! The file transfer is still a bit iffy (I couldn't transfer the 4 meg WAD file, so I had to split it into 3 smaller files, then write a small program to merge them back together), but I can't complain, since the emulator is a blessing enough by itself. Good work!

What I'd really like is a GIF xD

Tell me how to make them without hassle on nspire_emu, and you'll get one ^_^

Oh, and thanks for the kind words, everyone. Glad to see my work appreciated ^_^