#146761 - XDelusion - Sat Dec 08, 2007 10:47 pm
http://starwarslegacy.net/NDS.aspx
I am not sure that my Star Wars project for the Nintendo DS will be finished in time for Christmas. I have a lot of work done, but recently found that the DS port of PrBOOM is not friendly to translucent walls, 3D floors, which my maps were full of. As it happens when you get close to a translucent window, the game slows to a crawl. If you so much as have a 3D floor within your line of sight the game also slows to a crawl, thus I am going to have to alter a number of things in many of my maps and perhaps reduce there size. Needless to say I wanted to release something for the holidays which is when Batman DOOM came to mind.
All you need to know about this classic Total Conversion can be found on the links below. This is not my own project, my only contribution is merging the TC into FreeDOOM which means you DO NOT need to own a copy of DOOM or DOOM II to play this. Merely copy the files onto the root of your Memory Card, launce Batman DOOM.NDS and you should be up and running.
I've not played through this on the DS, so if you experience any problems feel free to contact me on my site listed at the bottom of this text. If you report errors, BE SURE to be as specific as possible. I'll need to know what level you were on, what weapon you were using, and what was going on at the time of the crash or what ever.
http://doom.wikia.com/wiki/Batman_DOOM
http://www.doomworld.com/batman/main.shtml
http://freedoom.sourceforge.net/
http://www.dsdoom.com/index.php
Packaged by:
XDelusion 12-08-2007
http://starwarslegacy.net/
#146830 - XDelusion - Sun Dec 09, 2007 9:59 pm
I've made it to level 4 thus far and here is what I've experienced on my M3 Simply:
If you try to save on level 1, you may goto a black screen (lock up).
On level one when you turn the corner to enter the sub-way there seems to be a temporary decrease in frame rate.
If you try to save on level 3 you may goto a black screen, but it seems less probable when saving on level 1.
When you complete level 3 the system may lock up while trying to load level 4.
If level 4 does load up, you will notice a major decrease in frame rate!
Not all sounds play, or are balanced as they should be and are on the PC port of PrBOOM.
This is as far as I've played. I have noticed that this port of PrBOOM does not allow you to save over old save files (still), and will not allow you into the control options without locking up. It seems there are updates here and there, but none of them have tried to adress major issues such as these. I'm also not sure why my project and Batman DOOM's level 4 seem to cause the DS to slow down as I've not had any issues (yet) playing normal DOOM.
Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware.
#146831 - tepples - Sun Dec 09, 2007 10:02 pm
| XDelusion wrote: |
| Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware. |
In theory, it shouldn't; Doom officially runs on a Super NES, an Atari Jaguar, and a GBA. But in practice, some homebrew port developers may not have talent and dedication matching that of simonjhall.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146842 - XDelusion - Sun Dec 09, 2007 11:57 pm
It would be nice if Simon took a crack at the PrBOOM source code! ;)
I wonder if DOOM would make better use of expanded memory?
#146859 - simonjhall - Mon Dec 10, 2007 10:12 am
1) No...way...
2) No chance, that RAM is dog slow. Unless the game is actually out of RAM adding lots of super-slow RAM is only gonna make it worse.
I was actually wondering - does Doom on the DS use a software renderer or does it use the 3D hardware?
@tepples, thanks man :-)
_________________
Big thanks to everyone who donated for Quake2
#146896 - dahun - Mon Dec 10, 2007 10:54 pm
| tepples wrote: |
| XDelusion wrote: | | Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware. |
In theory, it shouldn't; Doom officially runs on a Super NES, an Atari Jaguar, and a GBA. But in practice, some homebrew port developers may not have talent and dedication matching that of simonjhall. |
u forgot xbox and ps1
#146897 - Markzilla - Mon Dec 10, 2007 10:58 pm
| dahun wrote: |
| tepples wrote: | | XDelusion wrote: | | Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware. |
In theory, it shouldn't; Doom officially runs on a Super NES, an Atari Jaguar, and a GBA. But in practice, some homebrew port developers may not have talent and dedication matching that of simonjhall. |
u forgot xbox and ps1 |
He was talking about low-power systems that it runs on.
#146909 - XDelusion - Tue Dec 11, 2007 4:14 am
I talked to Wintermute last night in IRC, he was saying that the memory cards are too slow as well. He also stated that Translucent Walls in DOOM are resource hogs and should not be attempted in the DS port because of resource restriction, so I'll scrap those and use old school window effects via texture.
What I don't understand is how DOOM can be released on the GBA on a GBA cart which goes into SLOT 2 none the less, yet SLOT 2 is too slow to use for extra memory, or is it just that the available memory expansion cards are merely made to slow.
Also I'm not understanding why DOOM seems just as resource intensive as Quake (well almost) yet it isn't true 3D and uses sprites instead of polys. I understand that Simon is a master of his art and has done the impossible, none the less, DOOM is on the GBA of all things, I would comment about the SNES port, but if you play that things you'll quickly realize it is not DOOM, at least not a respectable presentation anyhow. :)
I just hope I can work out the problems I'm having with this port, I'd hate to only be able to release this on PC's with PrBOOM, and possibly the PSP. I was looking forward to playing my creation with touch screen! :)
#146915 - elwing - Tue Dec 11, 2007 8:32 am
| XDelusion wrote: |
| What I don't understand is how DOOM can be released on the GBA on a GBA cart which goes into SLOT 2 none the less, yet SLOT 2 is too slow to use for extra memory, or is it just that the available memory expansion cards are merely made to slow. |
i'm guessing that the gba version is tailored for the GBA hardware and use only the GBA ram. the slot-2 might then only be accessed to load data... the slot2 performance is a problem when using the EXRAM not when loading data it seems. I'm also almost sure that the .wad used for GBA doom are scaled down .wad and that it should not be able to run regular .wad file... now that are only wild guess... if someone could confirm or deny these i'd be happy
#146916 - Cid2Mizard - Tue Dec 11, 2007 9:55 am
Don't works with my M3 CF slot-2
_________________
www.nintendomax.com 100% Hack 0% Warez
#146921 - wintermute - Tue Dec 11, 2007 10:28 am
| tepples wrote: |
| XDelusion wrote: | | Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware. |
In theory, it shouldn't; Doom officially runs on a Super NES, an Atari Jaguar, and a GBA. But in practice, some homebrew port developers may not have talent and dedication matching that of simonjhall. |
Doom is limited on all of those platforms, none of them were straight ports.
It's also rather difficult not to find this comment ever so slightly offensive.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#146922 - kusma - Tue Dec 11, 2007 10:32 am
FIGHT FIGHT FIGHT!
#146923 - simonjhall - Tue Dec 11, 2007 10:39 am
Transparent walls shouldn't be too killer, but (if it's anything like transparency in Quake) then it's something that the bsp system wasn't originally designed to do. However map editors designed to support transparent bsps (the transparency is part of the world, right? not a model?) should be able to emit maps that won't cause the bsp code to go into overdrive.
Unless the slowdown is actually a rendering thing, in which case this could be because of the overdraw and the transparent stuff would have to be alpha-composited with the stuff behind it. Wintermute?
_________________
Big thanks to everyone who donated for Quake2
#146925 - wintermute - Tue Dec 11, 2007 11:00 am
| XDelusion wrote: |
What I don't understand is how DOOM can be released on the GBA on a GBA cart which goes into SLOT 2 none the less, yet SLOT 2 is too slow to use for extra memory, or is it just that the available memory expansion cards are merely made to slow. |
GBA Doom was majorly cut back to fit the system. I don't remember offhand exactly what was trimmed but, iirc, there were missing monsters and modified levels.
The SLOT2 RAM thing isn't quite as straightforward as people seem to think. The bus is 16bit and doesn't have the required hardware to enable 8bit writes so that makes things more than slightly awkward. There's also the small matter of SLOT2 devices being somewhat nasty to deal with FAT access and RAM at the same time.
Doom itself also has some interesting features which make it slightly more resource intensive than you might expect. Killing the floor rendering has a huge impact on the frame rate, even on the systems it was originally designed for.
| simonjhall wrote: |
I was actually wondering - does Doom on the DS use a software renderer or does it use the 3D hardware?
|
It's software rendered but we may take a look at using the 3D hardware in a future update.
One of the things I'd like to do is take what we learned from the initial process and work with the prBoom SVN with a view to getting the ds port into the official sources. That's something for some future date with a little more in the way of free time though.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#146928 - wintermute - Tue Dec 11, 2007 11:32 am
| simonjhall wrote: |
| Transparent walls shouldn't be too killer, but (if it's anything like transparency in Quake) then it's something that the bsp system wasn't originally designed to do. However map editors designed to support transparent bsps (the transparency is part of the world, right? not a model?) should be able to emit maps that won't cause the bsp code to go into overdrive. |
Transparency is basically just a special case doorway/portal kind of thing. You'll see windows of sorts even in the original doom levels.
| Quote: |
Unless the slowdown is actually a rendering thing, in which case this could be because of the overdraw and the transparent stuff would have to be alpha-composited with the stuff behind it. Wintermute? |
And there you hit the nail on the head. The Doom engine *really* wasn't designed for this kind of abuse. I'd need to go back and check how prBoom does things but, from what I remember of the Falcon Doom clone we did many years ago, the column rendering is designed to render floor and ceiling sections, closing the column to further rendering when they meet in the middle. Here I'm referring to the "walls" made by sector heights rather than the flat sections. It's essentially a highly specialised raycasting voxel engine and has obvious roots in the Wolfenstein engine.
If you want to insert a transparent texture for something like a window frame in there then you're doing some nasty stuff with the way the columns are built. For instance you can no longer depend on clipping against the top and bottom limits but against the entirety of the opening where the texture is placed. From a brief look at the prBoom code it looks like they're calling realloc to extend the column buffers at that point so I'd be a tad worried about performance on the DS there. Yay for coders on high end desktops ;)
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#146931 - XDelusion - Tue Dec 11, 2007 2:40 pm
"One of the things I'd like to do is take what we learned from the initial process and work with the prBoom SVN with a view to getting the ds port into the official sources. That's something for some future date with a little more in the way of free time though."
What is PrBOOM SVN ?
As for the transparent Windows, they seem fine to me, as loong as you do not walk RIGHT UP to one. So if there is something putting some space between you and the window, you seem fine...
...though I'm not sure if these transparent windows are keeping the game from saving, or causing the system to lock up during level loads though.
I wish I had an old 166Mhz machine handy so I could put PrBOOM on it for testing.
Is there an X86 emu out there that allows you to adjust the virtual system's speed?
As for the various DOOM ports being cut back, that I understand...
...I was just wondering mainly how they loaded data from the WAD file fast enough for the GBA port, but you've already explained that.
#146932 - kusma - Tue Dec 11, 2007 2:56 pm
| XDelusion wrote: |
| Is there an X86 emu out there that allows you to adjust the virtual system's speed? |
Yes, DOSBox
#146933 - wintermute - Tue Dec 11, 2007 3:11 pm
| XDelusion wrote: |
What is PrBOOM SVN ?
|
mainstream prBoom source repository.
| Quote: |
...though I'm not sure if these transparent windows are keeping the game from saving, or causing the system to lock up during level loads though.
|
I'm pretty sure they're not - it's more likely to be a dodgy DLDI than anything to do with the in game data.
| Quote: |
I wish I had an old 166Mhz machine handy so I could put PrBOOM on it for testing.
|
DS is 66MHz but probably of equivalent power to somewhere around a P120, depending on what it's trying to do.
| Quote: |
...I was just wondering mainly how they loaded data from the WAD file fast enough for the GBA port, but you've already explained that. |
Actually I didn't explain that part - the answer is, they didn't. The WAD file is just sitting there in memory.
That gives me an idea though - it might be possible to read some things directly from cart space, with the exception of the audio data, assuming the WAD is under 32megs ...
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#146946 - tepples - Tue Dec 11, 2007 8:49 pm
| wintermute wrote: |
| tepples wrote: | | XDelusion wrote: | | Also it would seem to me if Quake can run so well on the DS, that DOOM and expanded Wads should not be an issue for the hardware. |
In theory, it shouldn't; Doom officially runs on a Super NES, an Atari Jaguar, and a GBA. But in practice, some homebrew port developers may not have talent and dedication matching that of simonjhall. |
Doom is limited on all of those platforms, none of them were straight ports. |
You're right; this can be seen even in E1M1: some of the walls near the stairs to the first armor are missing.
| Quote: |
| It's also rather difficult not to find this comment ever so slightly offensive. |
In that case, I apologize. I meant only that talent varies from person to person. Some people are skilled at maintaining toolchains, others at writing file system code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146954 - XDelusion - Wed Dec 12, 2007 1:20 am
Oh ya, WinterMute, you were asking if the DOOM sound track(s) had ever been done in XM or MOD format I believe (correct me if I'm wrong).
Anyhow I don't think I had caught you in time, but the answer is YES:
http://files.frashii.com/~sp00nz/Doom/
Or the alternate link:
http://doomdc.tk
They Music packs are in the download section and are listed on the right hand side of th page. And of course this is my old Dreamcast DOOM page which I intended to expand past the Dreamcast, but have not updated it in a while...
...anyhow...
As for loading data from a Cart Space...
...if the WAD needs to be under 32Mb, then I'm sure I can work with that. Granted Batman DOOM was BIG, but that's because I merged one WAD into the already oversized FreeDOOM, but since my Star Wars project is being done by hand, I'm sure in the end the file size should still be close to 20Mb I just need to chill on the maps and start making them a bit smaller as most of my maps as of late have been sizing in at a Mb or larger. :)
Also I did want to thank you fro choosing PrBOOM as your port of choice, not only is it DEH compatable, but it is also limit removing, and seems to fully support MBF (Mans' Best Friend) which means you can have allied armies with you in your mission. In PrBOOM it is a mere Dog, but that can be adjust to what ever and what ever number of them. Also the Sky Transfer trick seems to be quite intact in PrBOOM! What version of BOOM is this code based on anyhow?
On top of that there is some BEX support which is really nice, as well as those translucent walls which I think I'll keep around so long as they are not the source of my lock ups and crashes.
Oh another thing. In the PC version of PrBOOM if you keep kitting the PLUS sign to increase the screen size, you can pull up an alternative HUD which I like a lot but can't seem to acess on the DS. Infact I have tried to manually change the config file, but it seems to default back to what every you have set up already.
Also I know on the Dreamcast port of DOOM (nxDOOM) you could not save on some levels until X amount of enemies were offed, otherwise it would act like it was saving but actually would not. So I'm wondering if this could be causing any of the saving issues I'm havin on the DS and if so would it not hurt to set the config (or was that done via DEH?) to only allow 20 dead corpses per level or something?
And I don't know if I mentioned it, but sound is REALLY strange on DSDOOM, some sounds don't play, some are just right, and some can be hardly herd, but on the PC version, they play fine. The reason I bring this up is because I was using DeHackED to sacrifice some sprites to make looping ambient sounds from, but half those sounds are REALLY hard to hear on the DS. I can upload an example of my work if you'd like.
I've got more on my mind, but I can't think of it now, will adress later.
BTW my project page is here:
http://starwarslegacy.net/StarWarsDS.aspx