|
Post by angel on Aug 17, 2005 12:25:23 GMT 1
I just read a review of the official 3DRealms version of duke nukem mobile.
It seem really annoying, not interesting and bothering game. They cut out each level in some "small part" where you have to kill a bunch of "poping" mobs to get a key and open the door to the second "small part"....
Hoby Wan Tinnus, you are our last chance to get a decent port of duke nukem, 3DRealms killed their son...
|
|
|
Post by pdamonkey on Aug 17, 2005 13:35:31 GMT 1
I totally agree. I bought the game when I first got my Zodiac. It was a tossup between that and Doom 2. I played it once when I first got it and haven't touched it since. I loved the original on the PC and personally think it was the best game of it's kind for multi-player.
I know you're busy with the LJP project Tinnus, but I'm still looking forward to you starting this project.
Just imagine Duke 3D in the palm of your hand. Wow!
|
|
|
Post by metaview on Aug 17, 2005 20:18:16 GMT 1
I'm just giving it a try (sorry Tinnus), stay tuned, if it doesn't work until the weekend, I will drop it.
|
|
|
Post by Tinnus on Aug 17, 2005 22:28:52 GMT 1
No need to say sorry; I was actually thinking about asking someone since I'm still too busy with LJP. I should thank you (that means I can dedicate to my secret project... *hides away*)
|
|
|
Post by pdamonkey on Aug 18, 2005 9:30:31 GMT 1
I'm happy to see you having a go Metaview. I've been very impressed at the work you've done on the other projects.
Hope you manage to get somewhere with it. If you need any testing on a Zodiac just let me know.
|
|
|
Post by metaview on Aug 19, 2005 14:55:01 GMT 1
Ok, I decide to make this my online blog about the Duke3D progress or not...
Fr 15:50 The first try yesterday produced an executable but it was a mix from the original game source and some newer port of the engine/build stuff. After I got the whole stuff compiling and linking and started to do a run, I recognized that the real game logic was gone. Wasn't what I want, so I started another try. This time game, engine and build-stuff from the newer port (jfduke_3d). Now it compiles and linkes and runs and produces a black screen. But I haven't made any work on rendering yet.
|
|
kayge
Full Member
Posts: 134
|
Post by kayge on Aug 19, 2005 20:55:18 GMT 1
Some of us are watching your progress closely. Good luck and keep us updated.
I think I'm as excited about the possibility of Duke as I am about LJP 1.0.
|
|
|
Post by metaview on Aug 20, 2005 20:39:26 GMT 1
Sa 21:24 Ok, didn't had a lot of time during the day, but now I'm doing my slow way through the init stuff of duke3d. I was able to use at least the main c-source to source-level debug the windows port and see what's going on. ...to be continued
|
|
|
Post by angel on Aug 21, 2005 12:20:26 GMT 1
lots of people looks forward but we don't want to poluate this post
|
|
|
Post by metaview on Aug 21, 2005 14:13:41 GMT 1
So 14:39 If any one knows a better way to debug all this, he should stand up and speak. It's really painful: Adding debug output, compile (which takes ages for some files), copy to card, remove card from PC, put it into the Zodiac and run the game. Go through the crash, see (using the debug output) how far it goes. To find the place of the crash, you need several runs, to go deeper and deeper into the function stack. Once you've found the place of the crash, you may need to examine the parameters of the suspicious call and try to add the fix.
Several times these are long accesses to the memory with not properly aligned pointers. Stuff which seems to work fine with i386 processors, but fails badly on ARM.
The last big thing in the init code of duke was a pointer of NULL. Strange thing in a port, because you assume it worked on other systems before, therefore all pointers should be initialized somewhere. Ok, I looked for the place where the pointer was initialized and found it after some time in some other source file. I was quite sure, this place was called before the crash site. After polute the code with debug statements again, I've found it was a function call with parameters, but the actual function implementation (which I wrote as an empty function, because it was missing) didn't accepted parameters. Somehow, my pointer lost it's value during this. Now it's fixed and the code passes the init stuff. Even if it should already draw something to the screen, it's still pitch black and when the real game should start, it exits with a missing map message...
|
|
|
Post by Tinnus on Aug 21, 2005 15:31:58 GMT 1
I use Pilot Install to send the binary to the card instead of a card reader... not too fast transfer-wise but you don't have to take the card in and out.
|
|
|
Post by metaview on Aug 21, 2005 16:07:06 GMT 1
Tinnus: sounds a bit faster, will try it soon
@all: "use unsigned chars" seems to be an important flag for duke3d (but why do they use sometimes "byte" as type?) and, actually it does draw something to the screen, only the upper most line, but it draws :-)
|
|
|
Post by Tinnus on Aug 21, 2005 16:27:45 GMT 1
Wow ;D
Do you have a clue what the FPS might be when it starts to draw the entire screen?
And is it some random pixels or the real first line it should draw?
|
|
|
Post by metaview on Aug 21, 2005 16:47:03 GMT 1
No clue about the FPS, but it is already the real stuff, but everything is drawn to the first line. I've missed to setup a certain lookup table, as it looks like. It also does crash, when it is done with the first run of the main game loop. Looks like pointer assingment again (Trap 10 error).
Gotcha! It's drawing, but just in 8 bit :-) The inputs doesn't work at all, it goes straight to the first level then stops.
|
|
|
Post by dratatoo on Aug 21, 2005 20:27:54 GMT 1
Shouldn't it go to the main menu first? ;D
[Offtopic]BTW, I am unable to save in your version of Hexen, maybe you should look into it before releasing a new version. I've posted details in Yoyo's Hexen board.[/Offtopic]
|
|
|
Post by metaview on Aug 21, 2005 21:43:55 GMT 1
Yes it does. But then it jumps to the skill level and then the game starts. The 16-bit conversion is almost done. Next thing will be the controls and the double buffering. Sound is missing at the moment, and will be absent for the first release. About Hexen: I will have a look, but as far as I remember it works for the most current version. I will release it when my domain is on its new provider.
|
|
|
Post by metaview on Aug 22, 2005 20:34:20 GMT 1
Mo 20:52 Daily update: The screen gets rendered. The colors are very pale and dark. Don't know yet what it is. The start menus are still skipped without doing anything. The game starts and I can run around on the roof. Some parts are not rendered correctly and it crashes after a while. That's a pain...
BTW: No, sound doesn't work too
|
|
|
Post by Tinnus on Aug 22, 2005 20:56:33 GMT 1
You can actually run? What's the speed? ;D
|
|
|
Post by metaview on Aug 22, 2005 21:33:00 GMT 1
Speed: not many FPS, I would guess. I have to add something to measure it. But the render code is not optimized in any way. Will do something more this week and release th is unfinished version to the end of the week. I'm away from the keyboard for a week. If anyone want to pick it up for the next week, I would be glad.
Run: yes, I killed already some enemies.
|
|
|
Post by angel on Aug 22, 2005 21:43:44 GMT 1
Nice, its growing everyday
*cheer*
|
|
|
Post by metaview on Aug 23, 2005 15:10:13 GMT 1
Speed: 8 FPS (480x320 pixel rendered) Color: brighter now, but somehow my version is mixed with 6 bit/colorchannel and 8 bit/channel palette entries. Crash: still there, happens very unpredictable, will be a pain to debug.
|
|
|
Post by metaview on Aug 23, 2005 21:11:45 GMT 1
Tu 22:05 Just another update: It looks better now. I have the FPS displayed in the upper left and it is around 8 frames per second. I found the reason for the unpredictable crash and could fix a visual bug, both was connected. Another visual bug is still there, and will be fixed hopefully still tonight. I also found the place where I removed the keyboard code for the menus, so the menus should back to work now. I only can say, it looks very, very promising. Maybe a bit slow, but I will add 320x240 with HW-scaling soon to gain some speed.
|
|
|
Post by metaview on Aug 24, 2005 21:30:56 GMT 1
Ok, switched back to 8-bit mode and used the yoyo's stuff to render the display as in ZDoomZ. This is just amazing. All visual bugs are gone and the speed is around 15 FPS. The brightness is still not correct, can be adjusted by the menu but will go back to quite dark whenever possible, argh... The menu is almost usable. I think, I will release it as a preview on friday.
|
|
|
Post by snempaa on Aug 24, 2005 21:49:25 GMT 1
great news! Really wondering how it would run on my T|C;)
|
|
|
Post by dratatoo on Aug 25, 2005 19:56:10 GMT 1
Hm, I just wonder: Waht is the default speed of the original (DOS) Duke Nukem 3D?
|
|
|
Post by yoyofr on Aug 26, 2005 17:24:56 GMT 1
it depends on which processor it's running, but probably about 20fps on a 486DX33Mhz if I remember well.... I remember duke3d was really slower than doom (but handles more complex scene...) btw, metaview, really nice work! I still have to update my webpages for doom & quake to include your work....
|
|
|
Post by metaview on Aug 26, 2005 19:49:44 GMT 1
Because, I will be away from the keyboard from tomorrow for one week, I released the current Duke3D state on my website: www.metaviewsoft.de The source will be appear tonight, as for the current versions on the other Z-Games too. If someone wants to play around with it, you may want to give me a short note.
|
|
kayge
Full Member
Posts: 134
|
Post by kayge on Aug 26, 2005 21:07:17 GMT 1
Just on a quick try I hotsynced the Duke3D launcher to my Zire72. Copied the .zdk, .con, .rts, and .grp files to Palm/Programs/Duke3d. I configured the controls and launched. Initial launch seemed good and then screen became unreadable with random colours. I had to soft reset to escape and was 5mb short of ram. Soft reset would not restore ram, I had to hard reset but no problem.
I will wait for further work by yourself and test again. I'm patient and enjoy the testing so have a good week off.
|
|
|
Post by snempaa on Aug 27, 2005 17:55:39 GMT 1
Duke3d crashes on both the T|C and the T|E, after showing the version numbers of the datafiles. Both with a fatal exception which causes a soft reset.
I'm using the data files of the Atomic Edition of Duke Nukem 3d v.1999
It also shows "initchach(): Initialised with 3671776 by..." on my T|C and with another bytesize on my T|E.
|
|
|
Post by dratatoo on Aug 27, 2005 19:28:11 GMT 1
Works nearly perfect on my Zodiac 2 (17 - 20 fps in most cases). I use the Atomic Edition Data files.
If the small bugs could be worked out then at least Zodiac owners would have a new major title on their handhelds.
Bug report and suggestions (Zodiac 2):
The option to assign buttons for "looking up" and "looking down" would be nice.
Brightness setting isn't saved and changes back to the default dull setting if the game uses flash effects (item pickups, pain indicator). Maybe the brightness value isn't passed through.
Saving doesn't seem to be possible.
You can't exit the menu with the menu button if you aren't one level deep in the menu. Example: You can only exit if you are in the graphics options.
If you die then it isn't possible to restart the level (quickload savegame) if you press the fire button.
Maybe if you are done with Duke Nukem, Blood or Shadow Warrior would be nice projects (both use the Duke 3D engine with a few hacks like "true room over room situations")
|
|