Hacking Doom 3 Source released, chances of a Wii port?

[DRS]

Exotic solution, it would take away some pain. I work with old stuff and in my case a SDCard is slow too. It takes about 8 seconds to store a 640x480 screenshot on the 2GB card I´m using (writes about 120KB/sec I quess). Perhaps USB HDD is fast enough. Getting vmem to work correctly might be tricky though.

I looked through the code a little more. Saw a disturbing idCommonLocal::LoadGameDLL( void )... Hopefully the DLL code is included within the source tree otherwise I have to investigate if the Linux version uses it as well.

 

[tueidj]

id started using "virtual machine" DLLs back when quake3 was made, since it greatly simplified things like expansions packs and add-ons.

 

[DRS]

Yes, but x86 DLL is no use on a PPC. But I think the 'game' code is included so when it builds its included in the executable. I started creating a ogc version of sys.cpp and making the header files compile. Hopefully I can get something visual within several months

 

[tueidj]

The code will be there, but if it's designed as a dynamic library you'll have to fix up the static entry point function (VMStart or whatever it's called) that is intended to assign all the dynamic function pointers. At least that's how it was with quake3.

 

[DRS]

Thanks, useful knowledge, I'll see what is required when I get there. Nice to know that you have some ID software knowledge, might be of great help to me!

For now I need to create a small tool that mocks up the cpp files so that I can get the main loop and filesystem functions working w/o compiling everything. I currently have sys_ogc.cpp, common.cpp and str.cpp compiling, but a lot of linking errors ofcourse. That should be fixed with the mockups. When I was doing quake tenebrae I did mocking by hand, but Doom has a lot more files

Oh, and I postponed the Tenebrae port. I think Doom performs too.

 

[snakepliskin2334]

why would anyone bother with a port for the wii i mean the concept sounds good but the graphics are going to be pardon my french shitty wouldnt you think ? so why even try to port doom 3 ?

 

[DRS]

but the graphics are going to be pardon my french shitty wouldnt you think ?

In comparison to what? It won't be handling ultra mode at 50fps no.

so why even try to port doom 3 ?

My curiosity I'd guess. Will it be hard, how will it look, how will it perform. And I'm a complete retard too. Though, I'd rather see some youngster do it, I have some other tasks around here too.

 

[DRS]

I almost wrestled my way through the initialization phase now. At this point it uses about 22MB of DRAM and 20MB of SRAM. I was able to ditch 10MB of global allocated blocks, otherwise it would use 30MB which doesn't fit in SRAM and would make the application fail loading. It mainly reads all declarations, scripts, guidefs, images etc. I do get some warnings though:

------------ Warnings ---------------


during DOOM 3 initialization...

^3WARNING: ^1file def/char_sentry.def, line 307: Expecting '{' but found 'char_sentry_fire'

^3WARNING: ^1file def/char_sentry.def, line 307: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 320: Expecting '{' but found 'char_sentry_active'

^3WARNING: ^1file def/char_sentry.def, line 320: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 327: Expecting '{' but found 'char_sentry_cant_reach_player'

^3WARNING: ^1file def/char_sentry.def, line 327: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 335: Expecting '{' but found 'char_sentry_damaged'

^3WARNING: ^1file def/char_sentry.def, line 335: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 342: Expecting '{' but found 'char_sentry_destroyed'

^3WARNING: ^1file def/char_sentry.def, line 342: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 349: Expecting '{' but found 'char_sentry_destroyed_damaged'

^3WARNING: ^1file def/char_sentry.def, line 349: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 356: Expecting '{' but found 'char_sentry_sight_enemy'

^3WARNING: ^1file def/char_sentry.def, line 356: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 364: Expecting '{' but found 'char_sentry_sight_friendly'

^3WARNING: ^1file def/char_sentry.def, line 364: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 371: Expecting '{' but found 'char_sentry_open_door'

^3WARNING: ^1file def/char_sentry.def, line 371: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 378: Expecting '{' but found 'char_sentry_pain'

^3WARNING: ^1file def/char_sentry.def, line 378: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 390: Expecting '{' but found 'char_sentry_shutdown'

^3WARNING: ^1file def/char_sentry.def, line 390: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 397: Expecting '{' but found 'char_sentry_target_lost'

^3WARNING: ^1file def/char_sentry.def, line 397: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 405: Expecting '{' but found 'char_sentry_waiting_for_player'

^3WARNING: ^1file def/char_sentry.def, line 405: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 416: Expecting '{' but found 'char_sentry_step'

^3WARNING: ^1file def/char_sentry.def, line 416: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 430: Expecting '{' but found 'char_sentry_gears'

^3WARNING: ^1file def/char_sentry.def, line 430: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 450: Expecting '{' but found 'char_sentry_wakeup'

^3WARNING: ^1file def/char_sentry.def, line 450: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 458: Expecting '{' but found 'char_sentry_extend'

^3WARNING: ^1file def/char_sentry.def, line 458: Missing decl name

^3WARNING: ^1file def/char_sentry.def, line 466: Expecting '{' but found 'char_sentry_activation'

^3WARNING: ^1file def/char_sentry.def, line 466: Missing decl name

^3WARNING: ^1file def/monster_demon_pinky.def, line 280: Expecting '{' but found 'pinky_gears'

^3WARNING: ^1file def/monster_demon_pinky.def, line 280: Missing decl name

^3WARNING: ^1idChoiceWindow::InitVars: gui 'guis/demo_mainmenu.gui' window 'OS6Primary' references undefined cvar 's_numberOfSpeakers'

^3WARNING: ^1idChoiceWindow::InitVars: gui 'guis/demo_mainmenu.gui' window 'OS7Primary' references undefined cvar 's_reverse'

^3WARNING: ^1idFileSystemLocal::StartBackgroundDownloadThread: failed

^3WARNING: ^1idSliderWindow::InitCvar: gui 'guis/demo_mainmenu.gui' window 'OS9Primary' references undefined cvar 's_volume_dB'

^3WARNING: ^1Non-portable: path contains uppercase characters: base/apps/DoomGX/base/DEMO00.PK4/guis/guis/test

^3WARNING: ^1Non-portable: path contains uppercase characters: base/apps/DoomGX/base/DEMO00.PK4/script/script

^3WARNING: ^1Non-portable: path contains uppercase characters: base/apps/DoomGX/savedir/base/script/script

45 warnings

Can start porting some graphics soon I hope. That's what it's all about ofcourse

 

[snakepliskin2334]

good luck to ya

 

[XICO2KX]

Maybe some good news from John Carmack himself!

@GeeckoDev It will take some effort to get Doom 3 to run in 56mb. Try forcing no sounds and all textures to 64x64 to start.

 

[Maxternal]

Hmm, I'm not saying it can't be done but but although perhaps a little bit of virtual memory could help the RAM and the graphics minimum req isn't that bad given that here it lists a FX5200 under the PowerPC Mac's system requirements :
http://www.doom4portal.com/doom-3-system-requirements
What worries me is the processor clock speed requirements listed here, too. If all the processor's taken up computing graphic related stuff, it might be doable but the numbers worry me.

 

[DRS]

Maybe some good news from John Carmack himself!

@GeeckoDev It will take some effort to get Doom 3 to run in 56mb. Try forcing no sounds and all textures to 64x64 to start.

Kind of a nobrainer. But I pointed out the demo logging and server stuff to help the guy out

Hmm, I'm not saying it can't be done but but although perhaps a little bit of virtual memory could help the RAM and the graphics minimum req isn't that bad given that here it lists a FX5200 under the PowerPC Mac's system requirements :
http://www.doom4port...em-requirements
What worries me is the processor clock speed requirements listed here, too. If all the processor's taken up computing graphic related stuff, it might be doable but the numbers worry me.

From my QuakeGX mod I know calculating model shadows is most intensive, so I already figured that those must be used with care (adapt drawdistance for example). World shadows shouldn't be an issue.
Also, ppc-gekko possibly has Altivec, so perhaps a speedgain can be achieved from that. The Altivec SIMD code is already in Doom. Adding the compiler flag to my Tenebrae port made the game crash though...

 

[sabandellos]

@DRS

Hi, I think you should read this:

It's about the user realbrucest message in a spanish forum. He talks about a Doom+Voodoo2 patch. A downgraded version of doom3. Very very interesting.

I don't speak english perfectly, but if Google Translator doesn't do a right work, I can translate this for you.

this is the link Iam talking about:

http://www.elotrolad...407#p1729857612

I think you can use it as a base of your work instead of the pure id version.

Edit: More info, more help for you:

You can talk with Krzysztof Klinikowski also. He is porting Doom3 to Android devices. Here is his facebook: http://www.facebook.com/klinikowski

Thanks for the info to peligropowers and realbrucest , users from the spanish website ElOtroLado.net

 

[DRS]

@DRS
He talks about a Doom+Voodoo2 patch. A downgraded version of doom3.

Hi, thanks for the info. I read about that patch a while ago; the original thread dates from 2004. I think this isn't a source patch but a Voodoo GL patch instead as Doom source code wasn't available back then. Building a GL driver on top of Glide is easier (though, a lot more typing) than hacking Doom 3 executable to support old cards

The "problem" with WII is that it is a different beast than other platforms; It has GX instead of GL, two memory pools instead of one huge... On the WII, all code and memory allocations are done from the 24MB SRAM memory pool. Access to the 64MB pool must be programmed explicitly. To go a bit deeper into C++ coding, Doom allocates a lot of memory using operator new. Therefore the SRAM pool is on the edge of memory starvation without any effort. Ofcourse, C++ allows to override operator new so I can "redirect" some of the allocations to the 64MB pool. Doom also allocates a lot of memory globally; when the program gets to main(), only 10MB of SRAM is left uneaten. These global allocs cannot be redirected easily.

I'd really like to know how much memory is needed to load world and models. I currently have about 30MB DRAM left for that and I need a few Megs for textures as well. Compressed 256x256 textures only cost 32KB a piece so perhaps we don't need much texture mem anyways


reg,

Danny

 

[DRS]

Loaded the textures that come with the initialization; 20.7MB DRAM left. It is getting challenging now Hopefully Doom adds these to the image cache so that they can bedestroyed and reloaded as needed... Its not needed to keep stuff such as splashscreen and menu windows in memory all the time. Otherwise creating that will be the first thing to do after I get the client server thing done. But I'm going to try displayin the textures loaded first; I think it is the splashscreen and/or logo... Perhaps the console too. That stuff is still mocked so I don't really know what I get to see

I limit texture formats to I4 (4bits pp intensity maps), IA4 (2x4bits pp 2D normal maps), RGB565 (16bits color maps) and RGB4443 (16 bit color+alpha). I'm also going to use the supplied DDS files (DXT compression) as WII supports DXT1 but these aren't being loaded yet.

 

[XICO2KX]

Nice work, DRS!
Please keep us informed of your latest progress!
Oh, and if you need some technical help, you can always tweet John Carmack himself!

 

[tueidj]

Are you doing your own custom memory management? Libogc has this stupid quirk that means once you've dipped into MEM2, any unused memory in MEM1 remains unusable until all of MEM2 is freed again (which isn't likely to happen)... So for example if MEM1 had 4MB free and you malloc'd 4.5MB, a 4.5MB chunk of MEM2 would be allocated and the 4MB in MEM1 effectively get thrown away. It's really stupid and could have been avoided if the devkitpro devs had implemented mmap() instead of sbrk().

 

[Coto]

Are you doing your own custom memory management? Libogc has this stupid quirk that means once you've dipped into MEM2, any unused memory in MEM1 remains unusable until all of MEM2 is freed again (which isn't likely to happen)... So for example if MEM1 had 4MB free and you malloc'd 4.5MB, a 4.5MB chunk of MEM2 would be allocated and the 4MB in MEM1 effectively get thrown away. It's really stupid and could have been avoided if the devkitpro devs had implemented mmap() instead of sbrk().

Then why don't you submit this fix? Curious about it. It should help

 

[Selim873]

This is really neat!! Can't wait to see progress! An Android port for Doom 3 is already being worked on.

 

[tueidj]

Then why don't you submit this fix? Curious about it. It should help

Because it affects not only libogc but also the way devkitpro uses newlib, which in turn affects the other supported platforms (devkitarm, devkitpsp) that I have no experience with. Additionally I have already made it clear I won't support a project where the "maintainer" relies on the work of the community to improve it, yet refuses to take any suggestions from that community regarding how the project should be managed. If he wants to run it his way, he can do all the work himself - I am sick of fixing bugs in the existing code because it has all been hurriedly committed without the slightest bit of testing.