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
31
nDoom / Re: nDOOM - Work in progress
« on: January 24, 2011, 03:06:56 pm »
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 :banghead:. 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!).

32
TI-Nspire / Re: TI-Nspire GB Emulator
« on: January 22, 2011, 01:37:48 pm »
Since I don't have a Clickpad, I've hacked around a bit in assembly to make this great program work with the Touchpad - it's a really really ugly hack, and the ROM selection screen is still broken (always selects the first ROM in the list), but hey, it's better than nothing!
During testing, it used to crash quite a bit due to some memory overwriting, but I think I fixed it all... tell me if there are any crashes or things like that.

Edit: Oops, forgot to mention what keys I've remapped the controls too :-[ :
A - Tab
B - Ctrl
Start - Menu
Select - Del/Clear
Direction - 8/4/5/6

33
nDoom / Re: nDOOM - Work in progress
« on: January 21, 2011, 04:17:19 pm »
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! ;D), 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.

34
nDoom / Re: nDOOM - Work in progress
« on: January 14, 2011, 08:11:34 pm »
Well, sorry everyone for lack and slowness of updates, but not only does school take a long amount of time, but the bugs that are left are increasingly getting more and more obscure (the one I just fixed in this release, everything went wrong due to a single bit being zero instead of one... and this bit wasn't a boolean, it was inside a 4-byte int!) and thus take longer to fix.

Release features:
  • Rendering bug in level 2 fixed, this should be the final rendering bug (I hope)
  • Added loading screen (useful on real hardware, where the loading actually takes some time)
  • Playtested up to level 4 or so
  • Lowered default difficulty to easy, because I kept dying (still no menu, though...)
  • Manual weapon selection (finally! use A/B/C/H/I/J on Touchpad, or 1-6 on Clickpad)

The crash-on-exit, lack of automap, etc. are still all there, but at least now all the levels are playable and the game can be said to finally work (sort of). Further releases will concentrate on improving the experience (difficulty selection, improved palette, savegame support...).

A peculiar thing: With the introduction of the loading screen, the screen as a whole shifts slightly to the bottom left (~10 pixels in each is my guess). I remember that the particles demo had this bug, and it was resolved by not reading from the screen buffer - however, I am not doing that. All I'm doing is writing (memset and memcpy). I'll attempt to do a test case, but not sure if I'll have the time to do so. Nevermind that, I'm just an idiot.

Again, suggestions for better controls/misc improvements are always welcome. Also reports of crashes.

35
nDoom / Re: nDOOM - Work in progress
« on: January 08, 2011, 06:42:30 am »
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 ;D
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!

36
News / Re: First Calculator on IRC
« on: January 06, 2011, 10:50:37 am »
Yeah, this is way too awesome. I'd never think something like this would even be remotely possible...

Just out of interest, what kind of chip is that on the board you have? Since it's only one chip, I'm guessing it's some simple pre-programmed microcontroller, maybe 8 bits, but that's just me guessing. The electronics nerd in me wants to know the truth ^_^

edit: Ooops, I am such a noob. I've somehow managed to miss the bolded description of the board in the other topic...

37
nDoom / Re: nDOOM - Work in progress
« on: January 06, 2011, 10:35:15 am »
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 ;D

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.

38
nDoom / Re: nDOOM - Work in progress
« on: January 04, 2011, 04:50:54 pm »
Here is today's build. I've fixed level transition (however, level 2 has a big bug in the rendering, so this fix isn't very useful yet), added controls for contrast (plus/minus), an experimental alternate mapping for the Clickpad (I don't have one, so I have no idea about the ergonomics), and also changed the loader so that it looks for the WAD files in the current folder, and not necessarily the root.
I've also fixed another bug with the textures (which I accidentally introduced while debugging the last texture problem :-[), and the game looks even better now. Also, switches are no longer invisible:



Unfortunately, the reboot-on-quit bug ("Error at PC=FFFFFFFE: J mode is not implemented" in the emulator console) is still present - that, along with the rendering bug of level 2, are the top priorities for the next release. Hopefully I'll also have time to improve the HUD, so that you can tell the difference between picking up an item and taking damage.

For experimentation, I've also swapped the strafe/turn keys around. I'm not sure if it's an improvement in ergonomics or a step back, though.



I checked the new screenshot and it's awesome. How many levels of gray do you use by the way now? In the screenshot I only see 4 or 5 but I'm not sure if it's due to CalcCapture, low contrast or something else.
Thanks - it's supposed to use all sixteen shades, but I still have to shuffle the palette around a bit to spread the colours out and such. I think I screwed up on a couple of values while typing out the 256 bytes manually in hex...

PS: Yay! I just noticed I can upload files now. Both source and compiled version included ;D

39
nDoom / Re: nDOOM - Work in progress
« on: January 04, 2011, 02:35:59 pm »
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.

40
nDoom / Re: nDOOM - Work in progress
« on: January 03, 2011, 07:59:52 pm »
I keep getting this error. Is there a particular folder the .wad.tns is supposed to be in? I looked at the source and it seems to be trying to load .wad.tns files from the current directory, but I can't find where the current directory is set.

I think you have to send it to the root directory.  Sadly, I can't figure out how to do this on the emulator (when I try to copy-paste it, the emulator crashes).

First of all, sorry Goplat for not mentioning that in this release... I mentioned it the first two times, but forgot to do here  :-[

Anyway, to fix the copy/paste crash, there's another way to save it: Press the menu button, then select "save as", save to root directory, then delete the original. Horrendously overcomplicated, but gets the job done. I fixed the path because my dynamic approach kept crashing and I wanted to move on to the rendering engine... I've added it to my to-do list for the next release (hopefully tomorrow).

Critor, thanks for your kind words - the contrast adjustment will be in the next release as well, don't worry... but fixing the vertical textures took a lot of effort (even though it was a trivial bug in the end), and I was too lazy to do anything more for today.

Oh, and Goplat? Nspire_emu is AWESOME. Just thought I'd say that again  ;)

41
nDoom / Re: nDOOM - Textures bug fixed!
« on: January 03, 2011, 04:39:37 pm »
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 ;D

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.

42
nDoom / Re: nDOOM - Work in progress
« on: January 02, 2011, 02:50:14 pm »
OK, since everyone requested it, I'm putting up my current build of nDoom, with the biggest problems fixed (huge problems still remain, but at least you can see what's on the screen now).

Here's the distributable, along with the source, for anyone who's interested:
http://www.box.net/shared/mlravudct9

This is seriously unfinished, so don't say I didn't warn you!

Some known problems
  • Wall/Sky textures, obviously
  • Screen too dark on real calculator (funnily enough, yesterday it was too bright)
  • Gun refire laggy, although world movement fine for some reason (on real calculator)
  • Too fast (on emulator)
  • The quit function sometimes freezes/resets the calculator (something to do with the graphics shutdown function, I think...)

So yeah. Try it at your own risk. And thanks again to all those who replied! I hope the shortcomings of this release don't disappoint you...

43
nDoom / Re: nDOOM - Work in progress
« on: January 02, 2011, 08:33:07 am »
Wow, I thought the initial response was amazing, but people seem to like the gif even more ;D
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!

44
nDoom / Re: nDOOM - Work in progress
« on: January 01, 2011, 07:23:20 pm »
Whoa, I go off to try CalcCapture, and when I come back there's loads of replies! Thank you, everyone! Glad to see people like it.

Here's an alright, but 1.3MB, GIF for all those who want it (hyperlinked for those with low bandwidth):
http://img407.imageshack.us/img407/7279/20008.gif
[I don't strafe because of an annoying controls bug, which is evident near the end - I try and strafe to avoid the incoming fireballs, but warp over into the radioactive water and die]

For those who want the build, I'll put one up tomorrow (tns + source - but beware, there's been zero cleanup so far) when I've fixed the strafing, and hopefully also the textures [floors and ceilings are fine, but walls aren't]. I must repeat that I am working off the 1997 source release, and that I didn't do it all myself - mostly, I've just been translating system-specific calls and fixing bugs [I'll put up some of my observations in the Ndless thread, also probably tomorrow, as it's getting late now].

Critor:
I am not quite sure what defines raycasting (this is my first experience with a 3D engine), but I don't think Doom uses it; It's not a proper 3D engine, you can't have rooms above each other or look up/down. Instead, it uses lots of shortcuts and tricks to make it look like that.

ExtendeD:
Thanks for the link about the contrast - I've actually already noted down those addresses, but getting the 3D working has been the priority so far.
I've only been using the default nspire_emu to this point, but I'll look into Ncubate.
Oh, and there's nothing impressive about this. I just downloaded the Doom source, spent a week doing lots and lots of modifications [mostly because the original ID developers used lots of cheap hacks that worked in 1993 DOS, but caused trouble to the Nspire - also, rewriting the whole event system, as the original used function pointers with arguments, which the Nspire doesn't seem to like either], and that's it. Managing to bypass the protection and hacking the Nspire? Now that's impressive.

45
nDoom / Re: nDOOM - Work in progress
« on: January 01, 2011, 06:17:15 pm »
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 ^_^

Pages: 1 2 [3] 4