Once again, thanks for the kind words, everyone! Also thanks to the Omnimaga staff for this article.

I'll try and fix the remaining bugs ASAP, but whenever I have time I seem to get sidetracked by something completely different...

still, this is not quite up to par with WFRNG, but it is a start {/runs}

<takes out radio>Field battery 17, you have coordinates. Fire when ready!

First of all, I must take the time to thank the entire Omnimaga community. Although there were many troubles, bugs, and other technical difficulties associated with the first release of nDOOM, you nevertheless responded with great passion and encouragement. Without you, I probably would have abandoned the project soon after January 1^st, and would never have taken the time to sort through some of the more egregious bugs the project suffered through - namely the wall texture bug, or the crash-on-exit bug.

Now, finally, after many weeks of development (weekends, rather), the game has reached a state I would consider "fun". Although there is still no menu, difficulty selection, and no extensive testing had been conducted, there are now enough features to approach the original version, released for MS-DOS in 1993. All of you will welcome the addition of savegames, the main new feature of the beta release.


I seriously hope you guys are better players than me...

There remains one big problem concerning the controls, and that is the Clickpad key layout; Since I only have a Touchpad, my philosophy for control placement on that particular keypad consists of "Guess and pray". I would seriously welcome suggestions on how to improve it.

Action          | Touchpad | Clickpad
________________|__________|____________________________
Forward/Back    | 8/5      | Clickpad up/down
Strafe left     | 7/4      | Esc
Strafe right    | 9/6      | Home
Turn left       | ^        | Clickpad left
Turn right      | x^2      | Clickpad right
Shoot           | =/trig   | Clickpad centre
Melee           | EE/PI    | 1
Weapons 1       | A/B/C    | 2/3/4
Weapons 2       | H/I/J    | 5/6/7
Quit            | Esc/Home | Enter
Quicksave       |    Library key
Quickload       |        Flag
Use             |        Ctrl
Map             |         Tab
Contrast        |         +/-

The game is a bit hard to see at points, but I have found that this problem can be corrected via judicious adjustment of the contrast. The game is pretty dark even on the computer, and so visibility problems are not only to be expected, but even intentional half the time (those of you who have tried the first versions, however, should note that I've remapped the pallette severely and it is now significantly easier to see than in the early days).


Yes, I know about the secrets I missed... these GIF files get way too big as it is!

I have attached two versions of the release - the "b1" release contains the game itself, built for Ndless 2.0 (therefore compatible with OS's between 1.7 and 2.1), while the "b1_source" contains the source code in C, available for any budding programmers or interested persons to investigate; However, beware! It's full of hacks!

Many important features are still untested, so there'll still be bugfix releases. Furthermore, I do intend to get that silly menu working eventually. However, this version is playable enough already, so go give it a go already!

---

In 1993, we fully expect DOOM to be the number one cause of decreased productivity in businesses around the world.

In 2011, we fully expect DOOM to be the number one cause of decreased productivity in schools around the world.

Have fun

Thanks for the feedback, everyone! It really is appreciated.

I've noticed that the ClickPad right Key is not mapped correctly (we just can't go to the right)
When we press simultaneously right and Home keys, we fire.

On exit, the keyboard buffer is not empty, thus, all pressed keys have a direct effect on the OS, a bunch of actions without control.

For example, if we pressed "front" "left" "esc" "center" "enter", all those keys will be considered by the OS. Thus, we go up in the folder, we open the upper document (center), and we re-open it (enter). Imagine what I discovered when I exit the game =)

Thanks for reporting the right key doesn't work - there was a typo in the input code that caused it (and not just any random typo, but a typo which resulted in checking a completely different, but still existent, key!).

I've confirmed that the keyboard buffer doesn't get emptied on my calculator as well, but I'm not quite sure how to start fixing it; Should I be looking at the interrupt handler? Or something in the keypad controller? Other ndless programs don't seem to be experiencing this bug, so it's obviously possible.

Wohoo, sleep mode bug fixed! See the main nDoom thread for download.

In case any future developer encounters a similar "calculator won't wake from sleep mode after running app" bug, I'll document it here:
If you want to use the Nspire's timers for your own things, and want to reconfigure them, you must store the values that were originally stored by the OS and which you're changing (for me, those at 0x900D0010 and 0x900D0014) to a variable somewhere, then restore them before you quit the application; Apparently, the OS uses those in sleep mode (not sure for what, but it does).

Wohoo! It works! Thanks so much, people! I thought SCREEN_BASE_ADDRESS was some sort of hardware buffer in the LCD controller with sufficient memory already present there... no idea it was just mapped to a random location in the RAM.

However, now I am getting another big problem: There's no more crashing on exit, but if you go to sleep mode (with CTRL+ON), it refuses to wake up again. No idea if it's not waking up, or if it's just the screen that isn't turning back on. To fix this, you have to hard-reset the calculator.
Since the nspire_emu crashes if you attempt to engage sleep mode (Warning at PC=103755FC: Bad read_word: b00001bc), I can't really debug it.

To answer your question, Critor, it should now look in the current folder, not in the root. The bug you describe occurred often on earlier versions - have you tried with the latest release (e.g. the one attached below)? No error message is strange, though...

Builderboy, you don't get more resolution, but you get twice as many colours now (16, while before I was only using 8, since I was using bits 0-3 instead of 1-4), so the general result is a much better picture anyway

Silver Shadow, I don't think memory's getting overwritten here... it seems to crash independently of whether the wad file is loaded or not.

This might be it! :
A screen buffer is equal to SCREEN_WIDTH*SCREEN_HEIGTH/2, so this would be 320*240/2, not 320*240
Try using the constant "SCREEN_BYTES_SIZE" for the third argument of memcpy!

The screen buffer's that size only if you're in 4bpp mode... I'm using 8bpp (so I don't have to bother with nibble->byte conversion), where the screen buffer is indeed 320*240 (hence using SCREEN_BYTES_SIZE gives you only half the screen in this mode).
I wonder if I've screwed up while setting the display mode...

EDIT: Yup, I seem to have screwed up. Removing the writes to 0xC000001C (LCD configuration), and changing third argument of memcpy() to SCREEN_BYTES_SIZE removes all crashing. I'll see if I can fix this bug before sleeptime...

Good news!

I updated my version of this yesterday and I tried it with the clickpad keypad again - and it works fine!  I guess I must have been using an old version or something by mistake!

That's great to hear! I was beginning to worry there for a bit.

I've tested it on my Nspire Touchpad and it appears to work great the only error I've encountered is that it crashes when I hit ESC. I've also found that is easier to see when the colors are reversed. Would there be any way for it to stay reversed permanently?

Yeah, sorry about that crash on exit. I've been trying to fix it since day one... About the colours, I agree, but I've experimented with a permanently reversed palette and it just looks weird (hard to describe, just looks wrong in some way). Because of that, I'll try improving the palette instead of just leaving it reversed.

Meanwhile, I also have good news! The automap is now fully functional. Like everything else in this game, it's a bit hard to see, but still helpful enough. I'll work on making the player arrow bigger, so its direction is more obvious.
No save support yet, but I've got intriguing news regarding the crash-on-exit (note: may turn out to be nothing)... if I run include the "intmask= TCT_Local_Control_Interrupts(0);" line at the beginning of my code, random pieces of my code that worked before start to crash (the PC register somehow gets reset to 0x0000).
Also, I've run the crash-on-exit through a debugger, and it definitely crashes after all nDoom code has finished execution - meaning some memory critical to the OS (or possibly the exit routine of ndless?) is getting corrupted.