Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Mrakoplaz

Pages: 1 [2] 3 4

I'm... not quite sure what to say. I guess I'd better go work on that Clickpad-crash bug, then.

And once again, a serious thank-you to all of Omnimaga for being such a great community! I know I said that multiple times already, but I really do mean it; You are just so supporting and friendly, it's worth pointing out repeatedly ;D
Oh, and a mandatory special thanks to ExtendeD and geogeo as well, for allowing this to happen in the first place!

News / Re: nDoom for the Nspire!
« on: February 17, 2011, 01:32:38 pm »
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! >:D

nDoom / Re: Video of nDOOM running on a real calc (Re-uploaded!)
« on: February 17, 2011, 01:03:01 pm »
Hmm, that crash is VERY strange indeed. Must be unique to the Clickpad, as I haven't had any problems whatsoever, even with constant loading and saving, for 10+ minutes of uninterrupted gameplay, on both 2.0.1 and 2.1 (as an aside, I have found lowering the contrast from the default helps immensely with visibility).

However, I noticed you're using the "cut-down"  WAD. Before I start analyzing the problem, could you try using the standard 4MB one? There might be some mysterious data corruption issue related to that (since the "crash" seems to be the screen turning black, and not the classic "freeze" one would expect).
Also, the files don't have to be in the root folder any longer, so there shouldn't be a problem on 1.7.

Oh, and thanks for taking the time to put this up!

nDoom / nDoom - BETA!
« on: February 15, 2011, 10:45:05 am »
DOOM... on the Nspire!

A fully functional port of ID Software's famous first person shooter, now available on your calculator!

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 1st, 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.

Code: (Current controls) [Select]
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!

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

Quote from: nDOOM press release
In 2011, we fully expect DOOM to be the number one cause of decreased productivity in schools around the world.

Have fun ;D

nDoom / Re: nDOOM - Work in progress
« on: February 15, 2011, 10:04:25 am »
Sorry for not replying much, I've been busy.

I did, however, in a moment of spare time, manage to implement save game support, and I'll be putting the release up shortly - as well as finally taking advantage of having a whole subforum to myself!

EDIT: Also, the game runs just fine on non-overclocked calculators; The screenshots are taken at a low FPS to keep the file size acceptable, but on a real calculator it runs just great. Of course, nobody's stopping you from overclocking anyways...

nDoom / Re: nDOOM - Work in progress
« on: February 05, 2011, 05:25:35 am »
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.

nDoom / Re: nDOOM - Work in progress
« on: February 04, 2011, 02:55:08 pm »
OK, here's the latest release, and also the last pre-beta version; All that remains to be added are savegames, and we're out of alpha!

There are two main features to this release: One, there's no more crash on exit. You can run it as much as you want, and the calculator doesn't restart or explode or anything... at least so far.

And the second feature is something everyone will celebrate: Improved palette!

The difference might look big on the emulator, but on real hardware it's completely incredible! I mean really, a complete transformation, leaping from an image barely visible at the best of times to something that can even be played in a dark room illuminated only by the computer's LCD monitor!

The culprit? Palette data was shifted by one bit.
Yes, really. Turns out, I did all my colour->grayscale conversions accurately, but misread Hackspire and thought palette data was stored in bits 0-3, when in fact it was in 1-4. Essentially, this meant only 8 colours were being used. Fixing this doubled the amount of colours displayed, improving things immensely.

Next feature? Savegames, and improved Clickpad controls. After that, we're out of alpha!

Code: (Current controls) [Select]
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 (why can't the ON key be mapped?)
Use             |        Ctrl
Map             |         Tab
Contrast        |         +/-

An updated GIF (as well as finally using this new subforum; making new threads etc.) will come along with the beta. Meanwhile, enjoy this release!

Calculator C / Re: nDOOM - Fixing the crash on exit
« on: February 04, 2011, 02:08:15 pm »
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).

News / Re: CGPN: The Calculator Game Programming Newsletter
« on: February 01, 2011, 10:24:30 am »
Congratulations on getting this first issue done! I hope there are many more in the future :)

Much thanks for the whole paragraph about my project, it is definitely greatly appreciated. You've motivated me to fix the crash on exit bug, that's for sure!

PS: Yeah, I'm kind of slow at noticing these things... or checking my email, for that matter.

Calculator C / Re: nDOOM - Fixing the crash on exit
« on: February 01, 2011, 10:03:21 am »
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 :)

Calculator C / Re: nDOOM - Fixing the crash on exit
« on: January 31, 2011, 04:17:04 pm »
Well, it's not quite fixed yet, I've had that argument in there for a reason... right now, only the top half of the screen is displayed. However, no crashing, and I'm working on getting fullscreen back.
Also, I've figured out a problem with my palette settings - apparently, it's bits 1-4 that determine the screen brightness, not 0-3... that means I was only using 8 colours out of 16, which I think would explain the low contrast.
Depending on how long it takes to fix this bug, I should have a bugfix release out either tomorrow or Wednesday.

Calculator C / Re: nDOOM - Fixing the crash on exit
« on: January 31, 2011, 03:26:17 pm »
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...

Calculator C / Re: nDOOM - Fixing the crash on exit - Progress!
« on: January 31, 2011, 03:14:44 pm »
Great news! I've managed to narrow the bug down... to a most unexpected location.
The following lines of code, all from i_video.c, stop the crash-on-exit if commented out:

Code: (I_ShutdownGraphics(), line 114) [Select]
memset(SCREEN_BASE_ADDRESS, 0xFF, 320*240);
Code: (I_Flip(), line 131) [Select]
Code: (I_InitGraphics(), line 197) [Select]
memset(SCREEN_BASE_ADDRESS, 0x00, 320*240);

As you can see, they all copy data into the LCD screen buffer. I can't exactly leave them commented, because then you can't see anything ;D
What's stranger still is that at the start of the program, I call memcpy() to the screen base address five times (for the initial loading screen), and that works just perfectly. Obviously, something happens between those two events that screws up the LCD controller, somehow, initially leading to a crash when the OS interrupts are re-enabled after nDoom exits (it must be something with the interrupts, because if I call TCT_Local_Control_Interrupts(0), I don't get the crash on exit, but right away once the first of the lines above gets called).

Now, I am puzzled even more than I was before, but at least I'm slowly moving in on the source of this crash...

Attaching the source code so that persons smarter than me are able to investigate.

nDoom / Re: nDOOM - Work in progress
« on: January 29, 2011, 06:28:19 pm »
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.

Calculator C / nDoom - 8bpp bug, sleep mode bug [SOLVED]
« on: January 24, 2011, 03:25:17 pm »
As those who have been watching the progress of nDoom might have noticed, I've been fighting a bug that triggers a crash/restart (depending on the exact release) upon exit ever since the start of the project.
Before, I thought that it made sense, since I still had unfreed memory lying about when the program finished, and files that weren't getting closed. Today, however, I fixed up all those points, but the crash still remains; It is giving me a different error, but the end effect is the same.

Now, although I've got experience in computer programming generally, as well as in assembly specifically, I am quite a newbie when it comes to C, and so I wish to ask anyone skilled in this language - aside from unfreed memory and files not closed, could there be other causes for a crash that happens after the main() function returns? Or is it more probable that I've missed a free() somewhere? And could some 7 random bytes of unallocated memory somewhere really cause the calculator to restart (consistently, every single time the program exits)?
The Doom source I've based my project on uses some quite ugly hacks, so even outlandish suggestions are welcome, since one of those hacks might be triggering an extremely rare bug somewhere (note: although it uses some interesting hacks, it doesn't use any ASM() statements).

Furthermore, while the errors the emulator gives are extremely useful whilst coding in Assembly, am I correct in thinking that they're absolutely useless when coding in C, as the compiler abstracts most of the register/memory accesses away from the programmer?

Finally, could anyone explain what decides whether the Nspire just freezes, or also reboots, after a program crash? I've seen both, and there doesn't appear to have been much of a pattern.

Pages: 1 [2] 3 4