Anthony817 wrote:Thank God I got another person with me who has wanted Marathon fully working haha! Good news, mrneo240 actually got it to compile with the latest KOS toolchain, however he is retiring so he will make the project available so the updated source is out there in case Ian may want to try and update the port for example, or anybody else that could.
I finally setup a Dreamcast SDK this week and spent several hours with some of the old FPS ports, and I have a few things to share.
Quake 2 : To enable sound, it looks like only two lines of code needs changing, though I could be wrong. I have no real programming skills, writing most of my code in scripting languages, but it seemed to make sense.
This was my first time setting up a Dreamcast SDK and I didn't try to recreate Bero's, which I would need to do to compile his code, but the required version of his SDL port seems to be available from his SourceForge page.
I experimented with using the Quake 2 console commands to free up some memory, but no major gains were made.
I was able to play through the first two levels in their entirety and then play part way through the first level again before the memory was exhausted and the game crashed. I do think it'd be possible to get the first level playable with sound, but you'd need to compress the sound effects and maybe even cut some of the ambient sounds.
It'd be cool to get it working, but it's a fair bit of work for such a limited experience.
SIGIL : PrBoom is a limit removing version of the Doom engine, which is required to play John Romero's SIGIL, and I was able to get the game running on Bero's port of that engine.
Only the keyboard and mouse are supported, with no controller or memory card support. I've played through a couple of levels on my Dreamcast, with the midi soundtrack included. There's some performance issues here and there, but overall it's great!
I can't share my disc image as it includes the registered version of Doom, but I'll write up a guide on compiling it in the coming weeks. The method I used could also be used for other limit breaking mods.
Duke Nukem 3D : I hadn't booted up Bero's port of Duke Nukem 3D since he first released it, remembering it only as slow. However, I booted it up this week and was surprised to find that it's slow but smooth.
I found that the port is not suffering from slowdown in the traditional sense and that one change could cause it to run correctly.
Some games will base the speed of their actions (movement speed, etc) on the frame rate, whilst others will use a timer.
Typing DNRATE during gameplay will display the frame rate on screen, and Bero's port is actually running around 60fps! This caused me to research more about the Build Engine and I soon found out that it expects 120 ticks per frame.
Put simply, the game is running at half speed, but not because of bad performance.
In the video below, set the playback speed to 2 and you'll see that the game then runs at the correct speed. This means that if the timer in Bero's port could be changed, the game would run well.
Yeah Ian said a while back it was just a matter of changing some line of code or something to enable sound. But that still puts us in the same boat. The key to getting this working is maybe the levels from the PSX and N64 versions sine they were made with lower specced systems in mind, similar to the DC ports of Half-Life and Soldier of Fortune needing the levels cut up into smaller, more manageable sections to load up in memory.
There were actual projects on PC people did that brought the PSX and N64 versions over to the computer version of the game as mods. There were some pretty different levels on console versions so it would be a good idea to just focus on maybe swapping out the levels with those.
https://youtu.be/gWtXz5CJBXg
About Duke Nukem! That is fantastic news! I hope Ian sees this and takes a look at it! Duke Nukem is my favorite Ego shooter!
Ah shame about Sigil. My DC keyboard broke and the board on the inside is toast so unfortunately no way for me to play it so would be awesome if that could be given controller support as well. I wanted to try many of those doom mods with removed restrictions.
Mrneo240 has quake 2 port compiling on new kos.. It be a better starting point.. Problem with Bero's code is the custom changes to newlib and the file loading is not standard and course vmu functions control functions are kos1.1.7 there not compatible at all with dreamsdk and there is no working port of sdl mixer now..
If you try to recompile bero's duke nukem port you see it has custom sh4 asm functions that dont work on later GCC bunch of other things that you have to rewrite to get it to compile .. Bero's code is very scary place to be even the build system.. There not ported like normal he modded kos to linux file reading not the other way around meaning there not up port-able to NEW kos at all might as well start from new.. VIDEO SOUND CONTROLS are not compatible .. Also vmu all need to be brought up to date.. These will not compile on dreamsdk like there are.
Didn't even have any idea neo was doing a Quake port until deluxux mentioned it to me just a while ago on Discord. I agree a more modern port is the way to go.
I just wonder why I didn't know about it sooner. Guess he was not promoting it much?
Anthony817 wrote:Didn't even have any idea neo was doing a Quake port until deluxux mentioned it to me just a while ago on Discord. I agree a more modern port is the way to go.
I just wonder why I didn't know about it sooner. Guess he was not promoting it much?
Quake2 to is up port of bero's to compile on new kos it's releases with his HD dump.. Miles of work to get it to compile much better using gldc then any old crusty opengl from 2002/3
I posted the duke nuke 3d bero source that had been missing from the net for a very long time few years ago now.. I have got it to almost build few error left
After about 1 month of doing it i had to take a break working on it or i would quit all together it's that crazy making.. and a mess to read
Ah ok up-ported modern KOS of Bero's port. Like he was doing with the Marathon Trilogy. Ok that makes sense now.
Damn the more I hear about it the more I understand why you are reluctant to work on his ports. Sounds like he was a genius but his method of porting was just so different.
Anthony817 wrote:Ah ok up-ported modern KOS of Bero's port. Like he was doing with the Marathon Trilogy. Ok that makes sense now.
Damn the more I hear about it the more I understand why you are reluctant to work on his ports. Sounds like he was a genius but his method of porting was just so different.
Marathon port Mrneo240 did some work on it get it to build.. I worked on it a little while and it builds but it does not work at all.. Mrneo240 and me looking at it means a total rewrite to most of it.. Src is there from Mrneo240 If any one wants to look he included in his HD dump release
Overall it's good to hear that you guys (Mr. Micheal & Mrneo240) are working on these various games. I'm sure it's a daunting task either way you look at it. Dig through someone else's code and try to understand their with now outdated methods, or start from scratch with newer updated dreamcast programming. It will just take some time and hopefully you don't get burnt out in the process trying to do this all haha!
Smaller maps would be needed for fitting the sounds in to memory, but converting them from other games isn't trivial.
The N64 version of Quake 2 is actually built upon the original Quake engine, whilst the PlayStation version only references id code in its AI.
As far as I'm aware, the maps of the N64 version have never been extracted from the ROM. Some levels have been remade from scratch, but that's a lot of work and you may as well develop all-new ones.
It is possible to convert the geometry of the PlayStation version, but you need to manually replace all of the entities (lights, items, enemies, and triggers).
Either way, the main concern is that the game will still crash after a couple of levels, as it's not freeing up enough memory between them.
This is the same issue that affects the Dreamcast ports of the original Quake engine, but a routine could be introduced that deletes the assets from memory between each load. This would increase load times but prevent the game from crashing.
Anyway, the performance of Bero's port is excellent and I would like to see it expanded upon, but I think that the most practical effort right now would be to improve upon mrneo240's incredible nuQuake engine.
If someone were to replace the sound code, perhaps with that of RADQuake or Makaqu, and fix the few remaining visual issues, it'd offer a commercial quality experience and would be a huge benefit for the indie scene.
