V2 Ideas.

[doomhack]

Got a few ideas for a 'V2' of this project.

• Port to modern C. With GCC 14 we're getting build errors which we have to set compat flags to ignore.
• Can do much more targetted optimisation as I have written my own code profiler.
• Change the WAD process so building custom roms with IWADS/PWADS, you don't need to recompile the code.
• Full resolution floor texture drawing. I think we can do that without slowing down too much.
• MIDI music support. (Can libopenmpt do MIDI to XM?) Can we port libtimidity and have native MIDI support?

Feel free to reply in the comments with your wishlist.

Please bear in mind we still only have 256kb of ram and a 16.7mhz CPU.

[Kippykip]

Well, when Sakitoshi was porting music using OpenMPT, converting MIDI to IT wasn't so straight forward as there's a lot of midi sound channels in the doom soundtrack.
I found through trial and error having 6 channels at most during busy moments of the song seemed okay, while the rest of the soundtrack can operate at 4 or less. Definitely needed some manual work. I was planning to port the entire Doom 1 & 2 & Final Doom soundtrack but due to housing issues all my projects went on hold.

The other thing is the soundfont, openmpt extracts the midi soundfont into sound effects etc it would have to be recalculated
Unless the GBAWadUtil could do the conversion somehow?

Do we do a GBASfxUtil that extracts both the WAD sounds and XM files into the source directory? That way PWADs work well

[doomhack]

I spent a couple of weeks converting all the Doom 1 music. Not a fun task. I reduced them all down to 8 channels.

Doom2 music looks even worse to convert.

Libtimidity just takes midi files and spits out PCM data in the format you request.

It worked ok on the Psion 5 (18 mhz ARM) taking around 20% of CPU time with Psions horrible OS and sound driver in the way. I think this could be reduced.

[Kippykip]

I spent a couple of weeks converting all the Doom 1 music. Not a fun task.

I find it fun, plus I have a USB midi keyboard in storage I'm dying to use once haha, I hopefully can help out with this project again. I move into my new place in January, it's been so competitive

I'll take whatever option sounds and runs well
Doom 1's soundtrack I think was already converted by Sakitoshi using OpenMPT and the MS GS Wavetable, but it was a rush job (notes not aligned perfectly, but good enough to work)
Kippykip@8225175

When I was doing a couple TNT tracks, I was recreating them. First couple ones I had already did in Milkytracker before this project but they sounded terrible as didn't have good instruments.

After Sakitoshi told me about OpenMPT and the Midi feature, I moved over to that for tracking.
They sounded much better, just needed some slight polish.
https://kippykip.com/threads/wip-final-doom-evilution-impulse-tracker-soundtrack.1601/post-3027

Since you know Arm & GBA stuff very well, do the .IT or .XM files result in good performance over anything others?
I wouldn't imagine a GBA being able to handle some OPL emulation seeing that DSDoom struggled

[doomhack]

I found IT files make for the cleanest conversion. IT/XM/MOD etc all have slightly different features.

Since the files all get converted to the internal maxMod format, I can't see any performance differences between them.

The main performance difference is going to be how many channels playing together as the mixer has to do more work.

OPL sounds horrible. (Sega 32X anyone?)

Music on the DS would be so easy. Just use libtimity on the ARM7 and you have 4mb of RAM so even memory isn't an issue.

[Kippykip]

Music on the DS would be so easy. Just use libtimity on the ARM7 and you have 4mb of RAM so even memory isn't an issue.

I think back in 2013 when I worked on a DSDoom fork, I had to use some midi function from a Hexen port prototype, where the midi code came from a dos emulator for DS. The music sounded HORRIBLE, worse than the 32X.

But yeah DSDoom needs to be reworked from the ground up imo, port had a lot of stability problems but it was an early attempt I suppose.
This GBADoom project though is much more fun to work on because of the limitations and vibe. Plus I had a lot of nostalgia playing retail GBA Doom 2

---

But yeah with the formats MOD only supports 4 channels and is mostly for the Amiga, .XM and IT seem to be pretty similar to me but .XM was usually my goto as it works on a lot more tracking software. IT I think supports more channels though, but I guess it doesn't really matter if maxMod handles it all.

Either way I'd love to work on the soundtrack while sounding good on as few channels as possible, such a shame I can't move into the place I bought until January due to it already being tenanted under lease.

[Cavencruiser]

I spent a couple of weeks converting all the Doom 1 music. Not a fun task. I reduced them all down to 8 channels.

Doom2 music looks even worse to convert.

Libtimidity just takes midi files and spits out PCM data in the format you request.

It worked ok on the Psion 5 (18 mhz ARM) taking around 20% of CPU time with Psions horrible OS and sound driver in the way. I think this could be reduced.

I took a jab at converting the doom 2 music, check my fork

[Cavencruiser]

I was wondering, even with all these optimizations in place introduced in the experimental v3 build I am actually getting 1fps less than the previous build before the hiatus. Let me explain what's going on here: So basically, I modified the code in r_hotpath.iwram.c to make the floor and ceiling render at half resolution once again while retaining your optimizations, however despite the floor rendering at the half resolution (also getting a 5fps boost back from the drop introduced when you rendered the floor and ceilings at full resolution) the framerate is actually worse by 1fps compared to the older build before all the optimizations were introduced. What's going on here?

[doomhack]

Probably GCC15.1 regression.

I was seeing worse performance on my other project with new GCC.

Also, what music are you using? The 8 channel Midi's I pushed in V2.7 will hit the framerate vs the 4 channel chiptunes.

[Cavencruiser]

Probably GCC15.1 regression.

I was seeing worse performance on my other project with new GCC.

Also, what music are you using? The 8 channel Midi's I pushed in V2.7 will hit the framerate vs the 4 channel chiptunes.

I am using my fork check my repository on my page. can you verify that I am doing this properly please? Id like to restore the half res floor and ceiling while keeping your optimizations. I've also noticed how you removed the "ofast" param from the collum rendering and floor rendering loops. r_hotpath.iwram.c is the file in reference here

Cavencruiser@905a26b

[Cavencruiser]

Probably GCC15.1 regression.

I was seeing worse performance on my other project with new GCC.

Also, what music are you using? The 8 channel Midi's I pushed in V2.7 will hit the framerate vs the 4 channel chiptunes.

If possible, can you make the lift fix compatible with the v2 version so I can compile it without any errors? I just would like to have functioning elevators while not having experimental features which hurt performance.
Basically, Is it possible for you to post just a fix for the platforms on your main branch?

[Cavencruiser]

I have a question which doesn't really relate to this thread, but have no other means of contacting you directly.
Ok, so I blindly pulled some optimization for enemy logic from the main branch of doomhack into my branch. while ignoring all other changes outside the source and include folders does this perhaps degrade performance in some way (i haven't really noticed any degraded performance but was wondering if putting this code into my build would make it less optimized) or is it going to cause subtle enemy behavior errors? Cavencruiser@a8df74f#diff-9e710b4c15c115e87afffc393dea9a5f031607d4efec775aa451eafa69c58c8c
I noticed a performance boost in situations where there are a bunch of monsters packed together, but that is only because of the new addition of case specific code for that situation in ‎include/p_mobj.h
remember, ignore all other changes outside the source and include folders as I suck at making commits or edits since I'm really not a programmer myself but would like to take some optimizations which seem beneficial. Also, I'm not sure what adding void after mobj actors behavior does.

[doomhack]

There are some changes to P_DoNewChaseDir() which will really improve perf where monsters are trapped. (Eg: Doom2 Downtown)

2 optimisations here. It won't check the same direction multiple times anymore. This won't change behaviour.

I also have a stuck counter. So if a monster can't move anywhere, we don't try again on the next frame and only try again after a random 0-15 frame delay. This will slightly change behaviour. The rocket launcher trap in E1M9 might spawn monsters a bit slower...but the perf win is more than enough to make it worth it.

The commit you linked are C23 fixes. The old Doom code declares functions with 0 params and then calls them with 0,1 or 2 params. I fixed this by making them all take 2 params and passing NULL where they are not needed. It shouldn't change perf. It's a correctness fix.

[Cavencruiser]

There are some changes to P_DoNewChaseDir() which will really improve perf where monsters are trapped. (Eg: Doom2 Downtown)

2 optimisations here. It won't check the same direction multiple times anymore. This won't change behaviour.

I also have a stuck counter. So if a monster can't move anywhere, we don't try again on the next frame and only try again after a random 0-15 frame delay.

The commit you linked are C23 fixes. The old Doom code declares functions with 0 params and then calls them with 0,1 or 2 params. I fixed this by making them all take 2 params and passing NULL where they are not needed. It shouldn't change perf. It's a correctness fix.

Ok, so I forgot to mention that none of your optimizations were ported over to my branch from v3 besides this. With that being said, this will be completely compatible and beneficial even without the other optimizations? I had not noticed any issues as of yet but was concerned if these optimizations for enemy behavior had been made with the intent to utilize and reference to other code that you optimized, possibly degrading performance on my branch if I didn't include the optimized data path that in reference. I cherry picked this very specific commit since I noticed when a gun is shot and pinkies or any monster type are trapped together like in tricks and traps, performance absolutely tanked on the original build, but this commit saved at least 6fps from just porting it over to mine for this situation. I meant to reference all the commits in the source folder and include, not just the one I linked. (Ignoring every other thing changed outside the source and include folders) Cavencruiser@a8df74f

[Cavencruiser]

Basically, I was just wondering if I properly ported over the enemy behavior to my branch of the original version prior to the full res floors, and if the files I cherrypicked were rewritten with dependance on the other optimizations you have made. Optimizations such as the reciprocal calculation optimizations (which I hadn't taken anything from that commit, as my main focus was p_enemy.c) just to name one as an example. The actual rom compiled without any errors, but that doesn't always mean its safe. I also didn't notice any bugs as of yet, but am still not sure.

[Pi-Ksplover2343]

i know this isnt exactly related to V2, but with the engine here, could SRB2 be possible on the gba (or a very limited version of it)? i mean, it runs on the doom engine