#64558 - Dudu.exe - Fri Dec 23, 2005 3:32 pm
Well.. i studing C++ to make my own ports by im too noob yet =p ....
i Just want to know if some one is orking on it? as everety one know.. the source Code was released.. so it can be easly ported to DS... ( well not so easly for me =p )...
_________________
http://flickr.com/photos/stuffbox
#64560 - Lazy1 - Fri Dec 23, 2005 3:54 pm
As far as I know no one is currently porting duke3d, however if someone does want to take this up a sdl version is available at http://www.icculus.org/duke3d/.
Good luck, and if it's anything like how porting wolf3d was it'll be incredibly dark so let me know if you want the gamma correction code I used.
#64619 - zubiac - Sat Dec 24, 2005 9:38 am
| Lazy1 wrote: |
As far as I know no one is currently porting duke3d, however if someone does want to take this up a sdl version is available at http://www.icculus.org/duke3d/.
Good luck, and if it's anything like how porting wolf3d was it'll be incredibly dark so let me know if you want the gamma correction code I used. |
your wolf3d port (the preview) is just awesome and it will help other ones porting games, which use the same(or modified) engine(like "Rise of the Triad","Corridor 7","H.U.R.L.","Nightmare 3D" or "Blake Stone"),easier to the DS.
thank you
I guess duke3d uses a completly different engine though.
but maybe the already existing "hexen" and "heretic" ports would help...
_________________
Abusing Cube and DS with all sorts of homebrew and hacks.
#64653 - Kyoufu Kawa - Sat Dec 24, 2005 5:15 pm
Nightmare was not even close to the Wolf3D engine, AFAICT.
It's like comparing Keen 4, BioMenace and Monster Bash.
#64658 - m2pt5 - Sat Dec 24, 2005 7:13 pm
The only "other games" in Zubiac's list I recognize are Rise of the Triad and Blake Stone, and I don't remember much about Blake Stone.
I do remember, however, that RotT's engine was quite similar to Wolfenstein's, but RotT had some vertical movement. (Mostly via jump pads and lifts.) By "similar", I mean it used a block-based map system like Wolf3D, rather than a vector-based map system like Doom and later FPS games used.
Hell, I'd love to play RotT again just for the awesome Drunk Missiles.
#64665 - tepples - Sat Dec 24, 2005 7:53 pm
Rise of the Triad's engine can be seen as a height-mapped raycaster. If you make the map tiles even smaller, you end up with the voxel fields of Comanche.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#64680 - Kyoufu Kawa - Sun Dec 25, 2005 10:58 am
| m2pt5 wrote: |
| By "similar", I mean it used a block-based map system like Wolf3D, rather than a vector-based map system like Doom and later FPS games used. |
Quoted for absolute truth.
#64684 - Lazy1 - Sun Dec 25, 2005 1:08 pm
For whatever you decide to port, prepare for a lot of work.
Wolf3d is around 13 years old and even on fast hardware it doesn't run full speed all the time. Though replacing floating point operations should take care of that.
Doom for example...
- Replace all calls to alloca() with calls to malloc/free
- Add in DS filesystem code
- Write the input/sound/video driver
- Figure out how to reduce memory usage as right now, the DS does not have enough memory to run doom
I think the last thing is the hardest to do, but someone who really wanted to could probably find a solution to that in no time.
#64695 - FireSlash - Sun Dec 25, 2005 6:45 pm
| Lazy1 wrote: |
...
- Figure out how to reduce memory usage as right now, the DS does not have enough memory to run doom
I think the last thing is the hardest to do, but someone who really wanted to could probably find a solution to that in no time. |
Theres a GBA version of doom... considering the DS has 16x more ram than the GBA, I don't think its going to be THAT hard. :)
_________________
FireSlash.net
#64701 - tepples - Sun Dec 25, 2005 9:01 pm
| FireSlash wrote: |
| Theres a GBA version of doom... considering the DS has 16x more ram than the GBA, I don't think its going to be THAT hard. :) |
The GBA has 8 MB of word-addressed ROM plus 384 KB of RAM. The DS has only 4.7 MB of RAM plus a block device. If your bulk memory is a block device instead of a word-addressed device, it can take longer to swap things in and out of memory.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#64735 - FireSlash - Mon Dec 26, 2005 4:00 am
Ouch, pwnd by the hardware specs. Excuse my ignorance, I didn't develop for the GBA, just going off bits and pieces I pick up on the DS forums.
Allow me to introduce the FireSlash method of porting high memory 3d games to low memory consoles:
Sort the textures by their use, load as many as you can, and replace the rest with random ones already in memory. Nobody will notice, right?
Ok ok, maybe not. :(
_________________
FireSlash.net
#64738 - tepples - Mon Dec 26, 2005 5:18 am
| FireSlash wrote: |
| Sort the textures by their use, load as many as you can, and replace the rest with |
...plain old Gouraud shaded polygons. That's Nintendo's strategy at least on the N64 and GameCube.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#64759 - Sebbo - Mon Dec 26, 2005 1:05 pm
| tepples wrote: |
| FireSlash wrote: |
Sort the textures by their use, load as many as you can, and replace the rest with |
...plain old Gouraud shaded polygons. That's Nintendo's strategy at least on the N64 and GameCube. |
heh, it works at least
from what i remember of duke nukem 3D, the characters, enemies and pickups were (are) all 2D in 3D space...in fact, the walls were too, so the only big limitation is the textures
hmm, i also wonder if the bonus adult mode section will be included (you know, in the strip joint)
_________________
Here's some ideas I have for when I know enough to act on them, or for others to have a look at when they're bored: www.wayne.sebbens.com/ds_ideas.htm
#64772 - Lazy1 - Mon Dec 26, 2005 3:37 pm
Well, no one said it was impossible - Im sure a quick look through the source will produce many areas where memory can be saved.
So all you need to do is find a way to fit all the textures, sounds and sprites into roughly 3mb of memory.
#64795 - octopusfluff - Mon Dec 26, 2005 9:27 pm
| tepples wrote: |
| FireSlash wrote: | | Sort the textures by their use, load as many as you can, and replace the rest with |
...plain old Gouraud shaded polygons. That's Nintendo's strategy at least on the N64 and GameCube. |
But you have to admit, they can do it with sufficient style as to make it not ugly.
#64833 - Opium - Tue Dec 27, 2005 7:56 am
I just thought, I'd add Doom DS is being ported already :)
http://dual-soft.com/doomds/
#64834 - Sektor - Tue Dec 27, 2005 8:09 am
That's not a port, it's a remake.
#65300 - Mchart - Sun Jan 01, 2006 11:14 pm
http://jonof.edgenetwork.org/index.php?p=main
If anything, you would want to work with Jono on such an undertaking (Who receives help from Ken, thus he is the man to talk too). However, there is no point, as the DS would never be able to run full fledged BUILD games (even if you took out voxel support, which pretty much castrates the engines greatest feature).
#65891 - bananaboy - Fri Jan 06, 2006 5:04 pm
Hm it looks like Duke3d uses fixed point. Maybe the DS could do it? Also it looks like voxel support wasn't added in to build until well after Duke3d was released. It looks like there are the beginnings of voxel support in the build version that Duke3d used, but they are compiled out.
#65903 - tepples - Fri Jan 06, 2006 5:51 pm
What kind of CPU was needed to run PC Build games at 320x200 pixels?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#65907 - Lazy1 - Fri Jan 06, 2006 7:19 pm
From the 3D Realms duke nukem 3d page...
| Quote: |
* 486DX2/66 with 8 megabytes of memory and VGA graphics. We STRONGLY recommend a good Pentium with 16Mb of memory and PCI local bus video.
* For the SVGA modes, a VESA compliant video card is required. Please see your video card's manual for info on how to find out if your card is VESA compliant. If yours is not VESA compliant, you will need to use a software driver to provide this compliance. We suggest a driver such as Display Doctor.
* For game play, the following devices are optionally supported: Keyboard, Mouse, Joystick, Gravis Gamepad.
* The following sound cards/devices are optionally supported for music: Gravis UltraSound, Sound Blaster (all of them), SoundMan16, Pro Audio Spectrum, SoundScape, Waveblaster, Sound Canvas, Adlib, and General MIDI.
* The following sound cards/devices are optionally supported for sound effects: Sound Blaster (all of them), Gravis UltraSound, SoundMan16, Pro Audio Spectrum, SoundScape, Disney/Tandy Sound Sources.
* There is no support for the PC Speaker.
* Duke Nukem 3D is a DOS game.
|
Though it was ported to the GBA, but we could also say that it wasn't a direct port. Maybe the game code stayed the same but ran under a re-written engine.
#65931 - Dudu.exe - Fri Jan 06, 2006 9:26 pm
| Lazy1 wrote: |
From the 3D Realms duke nukem 3d page...
| Quote: |
* 486DX2/66 with 8 megabytes of memory and VGA graphics. We STRONGLY recommend a good Pentium with 16Mb of memory and PCI local bus video.
* For the SVGA modes, a VESA compliant video card is required. Please see your video card's manual for info on how to find out if your card is VESA compliant. If yours is not VESA compliant, you will need to use a software driver to provide this compliance. We suggest a driver such as Display Doctor.
* For game play, the following devices are optionally supported: Keyboard, Mouse, Joystick, Gravis Gamepad.
* The following sound cards/devices are optionally supported for music: Gravis UltraSound, Sound Blaster (all of them), SoundMan16, Pro Audio Spectrum, SoundScape, Waveblaster, Sound Canvas, Adlib, and General MIDI.
* The following sound cards/devices are optionally supported for sound effects: Sound Blaster (all of them), Gravis UltraSound, SoundMan16, Pro Audio Spectrum, SoundScape, Disney/Tandy Sound Sources.
* There is no support for the PC Speaker.
* Duke Nukem 3D is a DOS game.
|
Though it was ported to the GBA, but we could also say that it wasn't a direct port. Maybe the game code stayed the same but ran under a re-written engine. |
i guess with a good code optoimization make it work
i remember my first good card was a voodoo 3 ( 16 mb ) ... VEEERY after Duke 3d
but i allwayes playied it well on weak pcs.. even in one with 1mb videocard
_________________
http://flickr.com/photos/stuffbox
#65965 - bananaboy - Sat Jan 07, 2006 1:37 am
Duke3D, despite the name, didn't use polygons for rendering. It rendered the world in a very specialised way, using horizontal and vertical spans (that's the reason that looking up in the game looked so funny - it was a kludge done via shearing). So to get it working using the DS 3D hardware would be a major amount of work (you'd probably want to start from an OpenGL port).
The DS resolution is 256x192. That's why I'm thinking that a direct port might work (although much of the build engine is in assembly language). Hmm I wouldn't be surprised if Duke Nukem Advance used the same sort of span renderer that Duke3D used. Back in the day of pre-hardware acceleration it was a fast (if limiting) technique compared to a fully 3D engine (like Descent).
Also it looks like people have ported Duke3D to various other handhelds/PDAs.
Hmm who was it that ported Wolf3d? I was just browsing the sources and there is mention of "dynamically compiled scaling routines" -- is this referring to some sort of SMC? Is that possible/just as fast on the DS?
#65983 - tepples - Sat Jan 07, 2006 8:35 am
| bananaboy wrote: |
| I was just browsing the [Wolfenstein 3D] sources and there is mention of "dynamically compiled scaling routines" -- is this referring to some sort of SMC? |
Yes, it referred to just-in-time compilation of a separate scaling routine for each strip height. This worked on 80286 memory hierarchy. But given ARM conditional execution and "slow" memories used in the GBA and Nintendo DS, it might not be significantly faster than a simple column scaling loop.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66090 - Lazy1 - Sun Jan 08, 2006 4:27 am
Now adays, hardware accelerated rendering is the preferred method so a for things like wolf3d, doom, duke nukem 3d maybe it's best to re-write the engine and port the game to the new engine rather than the old engine to a limited platform.
I have been thinking about this for my nds wolf3d port, at each map load every room ( seperated by doors ) would be converted from 2d map tiles into 3d quads. I haven't thought about visibility yet, but that should be easy enough. The advantage to rendering the game this way are:
- You would never reach the 2048 poly limit ( well, for wolfenstein anyway ).
- Less game time spent drawing in software leaves time for other things.
- Smooth, 60fps gameplay.
By writing your own engine, you could even get quake working on the DS.
You would need to write your own engine though, but being written from the ground up ensures that the game feels at home on it's new platform rather than a port of the pc version.
#66096 - tepples - Sun Jan 08, 2006 5:20 am
Wolf3d determined visibility in screen space with naive raycasting, one ray per screen column. A port to native 3D hardware could determine visibility in world space with portal raycasting.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66104 - MaHe - Sun Jan 08, 2006 8:16 am
What about porting SNES version to DS (I'm talking about Doom)?
Heck, it's almost the same as PC version (although snesDS won't run it).
#66143 - bananaboy - Sun Jan 08, 2006 2:33 pm
Yeah, I was thinking that you might be hitting the limits of the DS if you used a proper polygonal engine, and that it might be worth doing it the original way. But maybe not? Duke3D doesn't draw all that much anyway. Hmm.. I'm excited about this now!
cheers
sam
#66160 - El Hobito - Sun Jan 08, 2006 5:16 pm
| MaHe wrote: |
What about porting SNES version to DS (I'm talking about Doom)?
Heck, it's almost the same as PC version (although snesDS won't run it). |
for a start the snes version is nothing like the pc version. theres no source code to it, it written on a totally different processor and makes uses of the superfx chip also, porting it would be total insanity!
would it be better to port one of the opengl versions of doom/wolf3d since they already convert them into 3d (also the new node builders remove a lot of the errors in the maps like t-intersections)
#66240 - tepples - Mon Jan 09, 2006 6:14 am
The Super FX chip is just a 20 MHz 32-bit RISC CPU, right? The ARM9 is a RISC CPU clocked at three times that. I'm not familiar with the Super FX instruction set, but if we can get some sort of static binary translation going...
EDIT: correctness
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Wed Jan 11, 2006 2:12 am; edited 1 time in total
#66252 - Lazy1 - Mon Jan 09, 2006 7:16 am
Static binary translation for doom?
Half the work is already done for you, just grab one of the dozens of doom engine ports and start hacking.
Hell, there may not even be memory problems - I may have just had some other code issues at the time I tried to port doom.
Though, working with wolf3d has taught me alot about nds hardware.
#66268 - zubiac - Mon Jan 09, 2006 11:22 am
| Lazy1 wrote: |
Though, working with wolf3d has taught me alot about nds hardware. |
speaking of that......how is it going?Any major problems so far?
The pre-version you released was already stunning...especialy the framerate.
_________________
Abusing Cube and DS with all sorts of homebrew and hacks.
#66315 - Lazy1 - Mon Jan 09, 2006 6:58 pm
Right now I have to deal with:
- GBAMP File creation bug
- Design and write a compressing filesystem for SRAM
- Finding an embedded romdisk in memory ( should be easy though )
All except the last one are especially preventing a new release since I would like to get saving working. The spear demo I embedded was fine without saving because it only had 2 levels.
Though my latest flashcart builds have had saving for a long time, it was ripped out at the last second.
Instead of only allowing saves at the start of every level, I decided to compress the large ( 35kb ) full wolf3d saves so that flashcart users could save anywhere at anytime.
Another issue is music, the FM OPL emulator that came with the SDL version and the code that uses it are horribly uncommented.
For example:
- A Function is called "Blah()"
- Hex values passed to the OPL emulator without any comments explaining what the values are or what they do
Either way the emulator doesn't work on the nintendo ds, I tried running it but somewhere a call to malloc() fails so I think it's too memory intensive to use anyway.