SNES Doom source released under GPLv3

[lunaark]

1 minute ago, Tic said:

Wow. What knowledge. (I never had an amiga I jump from 8 bits to snes/pc.). I have try follow the source code with the source using these snes9x emulator with debugger, That first part fortunly uses snes cpu, to find   the global variables in the rom. 

 

I follow it +- first execute few lines from and unknown file of the sources. And then it call to the ini.a file. 

 

But when he executed  the "bne ColdBoot" and jumps in theory to the coldBoot part, that the first chek is the debugger. It change totally. I'm not sure if it's simply because the compiler generated alot big of code to made the ifn blocks or because the rom is a diferent version from the source code, but it's a lot of code not present directly in the init file.A lot of subroutines. So I try find where it made the check exactly. 

 

create trace logs, i presume you're using that geiger snes9x debugger whatever it was? create trace logs for the 65816 and grep it against the source code, there is probably alot of stuff disabled in the repository. the defaults are listed as comments in the rlinc.i file

[xttl]

Seems not all settings in rlinc.i and rage.i match the released ROMs.

 

ROM and useTEXTURES are set to 0 in rlinc.i, useXBAND and useSCOPE are set to 0 in rage.i.

 

quick edit: actually, I read somewhere that SuperScope support would have been disabled in the European version? (probably XBand too, wasn't that a US only thing?)

 

@Tic what are you trying to do? Just a heads up, almost all of the game runs on the SuperFX chip, Randy wasn't lying when he said it's 99% GSU code or something like that.

[Dark Pulse]

Generally speaking any game using the SuperFX is going to run on the GSU. At that point the SNES is basically reduced to the leftover stuff - reading controller inputs, general game logic, what-have-you, since the actual rendering is being done on the GSU and is just getting dumped to the SNES' framebuffer.

[xttl]

10 hours ago, Dark Pulse said:

Generally speaking any game using the SuperFX is going to run on the GSU. At that point the SNES is basically reduced to the leftover stuff - reading controller inputs, general game logic, what-have-you, since the actual rendering is being done on the GSU and is just getting dumped to the SNES' framebuffer.

 

Well yes, but in this case even the game logic runs on SuperFX. Actually, this is something somebody at NESDev said they see as a potential speed optimization opportunity. Make more of the game run on the S-CPU side, leaves more time for the GSU to render stuff and not chug along at ~10fps.

 

This is the post I was thinking of

Edited July 23, 2020 by xttl

[Tic]

Y try view if the debugger was here and can be activated. And these cheat=0 to. Also if the demo mode was in the rom desactivated.

 

Nothing that need gsu only change 0 to 1.

 

Normally I found these things quickly.But I am  a z80 guy :D. 

[xttl]

If you search the source tree for useCHEATS you'll see it's not even used at all, the only place where it's mentioned in is the include file:

$ grep -r useCHEATS *
source/rage.i:useCHEATS         equ     0               ; 1=Enable CHEAT Codes

They never got around to implementhing them.

 

Also, the way these defines work is that if the ROM has been built with eg. useCHEATS=0 or useDEMO=0; you can't just go and change a 0 to 1 somewhere because none of the code between ifn useCHEATS ... endif or ifn useDEMO ... endif was assembled at all when building it.

[Tic]

Yep, true,it appear call legal directly. 

[RandalLinden]

15 hours ago, xttl said:

I just tried to build at least the parts of the ROM that can be built without the game data ripped correctly. I put al ofl the ACCESS x* binaries released by Randy so far to a directory which I added to the path on my emulated Amiga and ran smake in the source directory.

 

First problem I encountered was that the bumprev tool from ACCESS is still missing (perhaps Randy will upload it later). I commented out all three lines that refer to bumprev from the smakefile and could get some files to assemble, though for some reason smake will think the xa commands fail (even though they succeed) so it only assembles one file at a time. I still got rlram0-3.o, random.o, vectors.o, bank00.o and monitor.o to build succesfully (without any real errors from xa) by running smake repeatedly.

 

Next file after those would be rlram7.o, but it fails due to a real error from xa:

 

@RandalLinden, any tips/comments?

 

edit: well, I just commented them out and that file assembled too. It looks like for the next file I'd need some data. The command smake runs wants files RLDATA:WALLIMG/BANK[01-0D].DEF

 

Download the updated version of the ACCESS toolchain -- LTEXT was broken in the first upload and so I found another archive, rebuilt everything and uploaded a new set of tools.

 

You want ACCESS Phase 1A

 

https://github.com/RandalLinden/ACCESS/commit/bb7fa8328370c9131e70909f1c0f91a487d8f0a9

 

The LTEXT works perfectly in XA 3.62 (you're currently using 3.55)

 

Yes, bumprev does exactly what you expect -- I have to dig around to find a copy of it, though... but in the meantime commenting it out or making a simple empty script called "bumprev" will work just as well.

 

Rand.

 

Edited July 23, 2020 by RandalLinden

[RandalLinden]

12 hours ago, xttl said:

 

Well yes, but in this case even the game logic runs on SuperFX. Actually, this is something somebody at NESDev said they see as a potential speed optimization opportunity. Make more of the game run on the S-CPU side, leaves more time for the GSU to render stuff and not chug along at ~10fps.

 

This is the post I was thinking of

 

One optimization I like, but won't work fully is using mosaic every scan line to do the pixel doubling correctly... unfortunately, flats are't necessarily pixel doubled and everything doesn't align on exactly doubled pixels.
 

Had I thought of this during development, I would have aligned everything cleanly and likely been able to have flats textured.

Edited July 23, 2020 by RandalLinden : Add more info

[RandalLinden]

15 hours ago, xttl said:

@RandalLinden, any tips/comments?

 

edit: well, I just commented them out and that file assembled too. It looks like for the next file I'd need some data. The command smake runs wants files RLDATA:WALLIMG/BANK[01-0D].DEF

 

Look in the "make" and "convert" subdirectories -- there are a ton of scripts that generate all the data necessary.

 

You'll need to create an "assignment" for "RLDATA" somewhere... and that'll just be a directory (which could be called "RLDATA") and then add appropriate subdirectories like "WALLIMG" based on the scripts

 

Rand.

Edited July 23, 2020 by RandalLinden

[RandalLinden]

11 hours ago, xttl said:

If you search the source tree for useCHEATS you'll see it's not even used at all, the only place where it's mentioned in is the include file:

 

They never got around to implementhing them.

 

Correct; Cheats were never implemented due to lack of space.

 

Rand.

[Dark Pulse]

Congrats on getting out of newbie status, Randy - you should be able to post and PM as much as you like now. :)

 

I'm wondering how we can get around the GSU's 16 Mbit/2 MB ROM limit, because that's going to be needed for some projects (certainly for things like, say, expanding the code to Doom II). I'm not really a technical wizard on SNES stuff or anything like that (just a guy with some knowledge), but at a minimum it'd have to be something like bankswitching, wouldn't it? Question is how to make that work, since it's not something that's just "free" or could be done with what would normally be in a SuperFX cart, presumably - if that could be done then fitting in all the code and data wouldn't have been a problem at all.

 

It'd suck to have to code up an entirely new enhancement chip or an extended SuperFX (neither of which could exist in actual hardware, obviously - not without someone fabbing chips and carts, anyway; of course emulators or flashcart-based hardware could do that fine, as has been done with stuff like the MSU-1) just to get more ROM space access. Those 21 address lines are a real murder... add another three for 24-bit addressing and that's 16 MB of addressable ROM.

 

If you wanted truly "limitless" expansion, you'd make it theoretically capable up to the SNES' technical limits - 128 Mbit/16 MByte. In practice though it'd have to be slightly less, since some hardware stuff is mapped to ROM space as well, so only 117.75 Mbit/~14.72 MByte is actually usable for game addresses.

[Tic]

I have asked in the sd2snes thread  if is posible expand the limit rom. They have respond  me that technically  was posible. Probably someone can do it  if there some real project back. 

 

Anyway. Sd2snes is open-source. So here is vhdl code of the fx chip:  if anyone know verilog  can compile and modify it. 

 

https://github.com/mrehkopf/sd2snes/tree/develop/verilog/sd2snes_gsu

 

[Redneckerz]

Tangibly related, but Dread for the Amiga employs a similar philosophy, in that it uses a custom engine to get a Doom like engine running on a Amiga 500 with 1 MB of RAM. 

It uses a custom map format that Doom Builder can read. Perhaps a similar idea can be implemented for the Reality Engine?

 

[taufan99]

4 hours ago, Redneckerz said:

It uses a custom map format that Doom Builder can read. Perhaps a similar idea can be implemented for the Reality Engine?

Or perhaps we can ask the Doom Builder side of developers to add support for the SNES port maps? Just my two cents.

[Job]

I really hope that's a possibility. 

[Redneckerz]

1 hour ago, InDOOMnesia said:

Or perhaps we can ask the Doom Builder side of developers to add support for the SNES port maps? Just my two cents.

As soon as the mapping format (from the source code) is documented (if it isn't already) then why not? But i reckon Doom Builder will have to take into account Reality Engine constants. It looks an awful lot like Doom, but it is not Doom. So behavior can and will change.

Given that Doom 64 and DZDoom have modified Doom Builders supporting their map formats, i reckon it will be a bit more work to support SNES since the engine is not Doom based but custom.

 

[Gez]

A map converter would probably be simpler; since after all it's not like it has extra mapping features absent from the original Doom format. We're not talking about something like the Doom 64 format -- which is still not supported by the Doom Builder family (except for the specialized fork) and only partially supported by SLADE.

[RandalLinden]

You should be able to create maps in any DOOM editor and then import them using the RIPDOOM tool.

 

When @xttl gets his side building cleanly, he'll be able to replace any of the maps with custom ones.

 

Rand.

[Roebloz]

We should probably ask @CacodemonTube as he knows how to make custom maps and he did that even before the source was released.

[Roebloz]

19 hours ago, Tic said:

I have asked in the sd2snes thread  if is posible expand the limit rom. They have respond  me that technically  was posible. Probably someone can do it  if there some real project back. 

 

Anyway. Sd2snes is open-source. So here is vhdl code of the fx chip:  if anyone know verilog  can compile and modify it. 

 

https://github.com/mrehkopf/sd2snes/tree/develop/verilog/sd2snes_gsu

 

200th reply, and that's good news

[Dexiaz]

36 minutes ago, Roebloz said:

We should probably ask @CacodemonTube as he knows how to make custom maps and he did that even before the source was released.

 

M0P0Z was the guy who wrote SNES Doom Builder before source code was released. CacodemonTube just helped M0P0Z with beta testing this thing.

 

BTW, you must recheck this thread.

[Tic]

I would try to compile it, but I have no idea of Amiga. 

[xttl]

19 hours ago, Tic said:

I would try to compile it, but I have no idea of Amiga. 

 

UAE/WinUAE isn't that hard to setup actually, you just need to get a Kickstart ROM and install floppies from somewhere, and you'll get used to the Amiga CLI pretty fast. At least enough for the purporses of building and using (or trying to use) Randy's tools.

I do not have any real prior experience of really using Amigas either. When I was a child, I did see some A500s but they were basically only used as just game consoles, albeit ones which take floppies instead of cartridges. At home, we just first had a 386-based PC, later a 486 and so on. Nobody I knew had a big Amiga with a hard drive or even an A1200, did anything serious with them, or knew how to really use them beyond booting X-Copy from one floppy and then making copies of other floppies with cracked games on them.

 

^{That, or drawing a few silly pictures with Deluxe Paint. I was a bit envious of some of the older games on their side because the PC versions were 4 or 16 horrid colors only crap, done before VGA really caught on, with some crappy beeper or OPL2 music. With newer software, the PC started to win because of more CPU power and not being gimped by a graphics chip that can only do bit-planar modes.}

 

Also, I give zero promises about delivering anything else than a functional SNES->PC map converter. All of you guys probably have a lot more love (obsession even) for SNES Doom than I do.

 

Btw. since the map format is a bit different (though many things are mostly equivalent to PC, just with a different name and/or optimized a bit), and because converting PC->SNES->PC isn't guaranteed to bring the exact original map data back (it seems not always possible due to the optimizations), I think stats taken from converted maps don't necessarily make much sense for the Wiki. I propose the SNES map pages should rather have eg. a face count taken directly from the SNES map data there rather than a sidedef count from a map that has been converted back to PC format.

Edited July 25, 2020 by xttl

[LindaIsHere]

if / when stuffing new maps into snes doom is finished I am %100 going to try and make a map that feels good to play in it.

[Redneckerz]

FastDoom features a flat shading mode making it appear like SNES Doom. It is decidely less quality, however, but it gives you a funky impression of how SNES Doom can look using the Doom Engine instead.

 

The author is aware of the SNES source code release and thinks its really interesting.

Edited July 29, 2020 by Redneckerz

[Dark Pulse]

14 minutes ago, Redneckerz said:

The author is aware of the SNES source code leak and thinks its really interesting.

Err... it's not a leak, sir, Randy Linden has released it himself and has even done some posts in this thread.

 

As punishment, record an Okuplok Tyson run.

 

*Goes off to get popcorn and a comfy chair*

[Redneckerz]

9 minutes ago, Dark Pulse said:

Err... it's not a leak, sir, Randy Linden has released it himself and has even done some posts in this thread.

... yeah i know, i just got it mixed up with the Gigaleak. I just do this inbetween work. (Which is a bad omen)

9 minutes ago, Dark Pulse said:

As punishment, record an Okuplok Tyson run.

 

*Goes off to get popcorn and a comfy chair*

Ill let Mike decide if it is good enough, considering the name.

[xttl]

42 minutes ago, Redneckerz said:

FastDoom features a flat shading mode making it appear like SNES Doom. It is decidely less quality, however, but it gives you a funky impression of how SNES Doom can look using the Doom Engine instead.

 

I think the biggest problem there is no depth cueing (flat color doesn't fade to dark in distance) based on the video. Even putting single color flats into regular Doom looks closer to the SNES version, though obviously it wouldn't be any faster on a low spec oldschool PC like FastDoom since it's still doing all the computations needed for texture mapping.

[taufan99]

Several days and no another news on this. I wonder if Randy has to take care of Phase 4's legal stuff as of now or is just cleaning up some of the code.