OptiDoom, my Doom port for 3DO.

4 hours ago, Redneckerz said:

I can't access your site atm, but are these things mentioned on your site? Because distortion and motion blur seem like really epic effects and unique to this port.

 

In any case Optidoom is highly impressive from day one.

Check out Optimus's youtube video for the 0.2b version. After the 28 minute of the video he shows off the gimmicks, the wireframe mode, the distortion effect, the spinning cube etc :D

1 hour ago, VGA said:

Check out Optimus's youtube video for the 0.2b version. After the 28 minute of the video he shows off the gimmicks, the wireframe mode, the distortion effect, the spinning cube etc :D

Thanks. Saw it and it looks really impressive, though its in full screen. But subtle buffers like the Atari Falcon port Bad Mood would definitely look fly :)

1 hour ago, Redneckerz said:

Thanks. Saw it and it looks really impressive, though its in full screen. But subtle buffers like the Atari Falcon port Bad Mood would definitely look fly :)

http://www.leonik.net/dml/sec_bm.py

Wow, that is interesting. Maybe Optimus can check out their ideas and code?

40 minutes ago, VGA said:

http://www.leonik.net/dml/sec_bm.py

 

Wow, that is interesting. Maybe Optimus can check out their ideas and code?

Doubtful, but hey. Bad Mood is extremely optimized for the platform, using the notoriously difficult-to-use DSP as a proto-GPU with various effects. Has been in development for several years and it shows. This is not a straight Doom port, but one to push the limits on its respective platform.

Interestingly enough I was looking at the source codes of GBADoom and ChocolateDoom for the R_MakeSpans function like here

The one that converts vertical visplane gaps to horizontal edges. I think it's a bottleneck on 3DO.

I was surprised the versions in the other ports look more clean and short than the one on 3DO (the big do-while loop in DrawVisPlane)

And I thought it should be slower, but looking it closer, algorithmically it seems to be doing roughly the same think as the others (comparing top bottom gaps from left to right, depending on inclination it will either mark horizontal edges or call to render a horizontal scanline)

But maybe, maybe... (and I haven't tested yet by converting the other codes, I need to be careful as it's a confusing code) the 3DO version was optimized to be doing less in the inner loop. While the others (chocolate doom, etc) are doing two checks in the inner loop (e.g. while (t1 < t2 && t1<=b1)) the 3DO code has some more if blocks, which however do these checks externally and ends up with a Count, it only increases it and does one check instead of more in the final loop.

So, I thought I could find something here (and I can still bother to try porting the other versions and measure (sometimes they do it with a while, sometimes with if, don't know which produces better code)) but it seems the 3DO programmer did the best to produce the optimal compiler code. I ask the compiler to display the produce ARM assembly code and man, it seems like it's pretty tight. All fit in registers, an ADD to increase, a CMP and a branch. I start wondering if there is less of a bottleneck here and more in the things happening in the later call to draw scanline (in MapPlane). Previously, when in my flat color visplane rendering I skipped this conversion and only drew vertical lines, at the same times I of course avoided the calls to  MapPlane. That's also why the flat visplanes without depth shading are way faster than the shaded untextured ones.

Anyway, still looking at it from time to time, at some point I'll change strategy and try to replace visplanes. But I wonder if there is a better algorithm for the conversion from vertical to horizontal edges. I kinda understand how this one works visualizing the pixels in my mind, but can't think of a better way of doing it.

I have found that the CD ingame loading problem that Optidoom has is an inherited problem from the original version. Extracted from https://www.gamesradar.com/uk/cheats/14548/

Quote

Cons: Games in progress cannot be saved (but a player may start a new game on any of 23 map levels previously conquered). No multiplayer ability. Overall game animation speed can be choppy, with frequent micro-pauses to access the CD, and animation noticeably slows down and speeds up with variances in the number of on-screen textures and sprites. This game uses the Jaguar Doom mapset (most of the maps in Atari Jaguar Doom are edited/simplified versions of the original PC Doom maps), and includes no other maps. No Cyberdemon or Spider Mastermind monsters. No light-amplification visors. No crushing ceilings. Weapons are cyclic-access only. First-person view does not fill the entire space above the status bar. Game does not utilize all available display space on the TV/monitor screen. The status bar can only display the ammo level of the currently selected weapon (in the PC, GBA and Xbox games, all ammo levels for all weapons can be displayed at all times).

On 10/23/2020 at 4:56 AM, viti95 said:

I have found that the CD ingame loading problem that Optidoom has is an inherited problem from the original version. Extracted from https://www.gamesradar.com/uk/cheats/14548/

 

 

A more up-to-date version of that FAQ: http://classicdoom.com/doomcomp.htm

Hmm, now it can beat the PSX Doom with extra effects :>

Can it be possible to make the game more like what's promised?

13 hours ago, The Strife Commando said:

Can it be possible to make the game more like what's promised?

Just use Phoenix Doom instead.

2 hours ago, seed said:

Just use Phoenix Doom instead.

I could not be right, but I don't think he meant this. The question is about possibility of the real 3DO hardware to handle Doom in better way than before. Phoenix Doom is good, but it's an imitation like GZDoom PSX TC is imitation of real PSX Doom. BTW, same story with PS1 releases - The Lost Levels for GZDoom PSX TC is not real thing but GEC Master Edition does for PS1 hardware. I suppose @The Strife Commando meant something like 3DO Master Edition version.

My answer for his question:

It's possible but only when FPS counter will be slighty fixed. 8 FPS for starting E1M1 room is not good mark, it should be at least 15, because a lot of rooms are just like E1M1 starting room and this is a slideshow. I do remember 3DO's CEL-engine was the reason why FPS is so low - due to wrong rendering of floors and ceilings per second the 3DO hardware spent more power to render it normally. But it's not easy to do something with this, I suppose.

But if this problem will be somehow fixed...

1 minute ago, Dexiaz said:

but it's an imitation like GZDoom PSX TC is imitation of real PSX Doom.

Um, no this is not correct.

Phoenix Doom is an actual port of the game which incorporates lots of fixes and enhancements over the original 3DO version, many of which can be disabled. This is very far from what the PSX Doom TCs were for GZDoom.

26 minutes ago, seed said:

Phoenix Doom is an actual port of the game

For PC?

No, this is what I've meant. According to this demonstration video Phoenix Doom is

Quote

a backport of 3DO DOOM to PC

Quote

version of the game to PC, Mac and Linux.

I don't care is this better than GZDoom TC in terms of quality, it's still the PC port.

Just now, Dexiaz said:

For PC?

Well, yes, that it is indeed, a PC port for the 3DO game, using the real data from the real game, and not a recreation of it.

Unlike PSX Doom TC, which was a TC for GZDoom. So I'm not sure what you mean here.

52 minutes ago, seed said:

So I'm not sure what you mean here

The hardware. PC is PC, even with 3DO data it will not became the true 3DO Doom with good parameters. It's the emulated version of the game which is not "canon" or "true" or "IDK how you will call it". Just an imitation.

18 minutes ago, Dexiaz said:

The hardware. PC is PC, even with 3DO data it will not became the true 3DO Doom with good parameters. It's the emulated version of the game which is not "canon" or "true" or "IDK how you will call it". Just an imitation.

I see.

Well in this case, agree to disagree.

On 1/11/2021 at 9:41 AM, Dexiaz said:

Hmm, now it can beat the PSX Doom with extra effects :>

... goodness. @Optimus Holy heck, it becomes more impressive by each and every build!

The colored lighting puts a heavy strain on the framerate. Is this a limitation of Madam and Clio accelerators (Cel Engine), or is there something else causing this (Like the ARM processor)?

18 hours ago, The Strife Commando said:

Can it be possible to make the game more like what's promised?

There is never a day where you actually are impressed by a port's work do you. Here you have a vastly impressive and improved port of one of the worst Doom versions out there, with fancy colored lights, improved framerate, even more graphical effects putting the underutilized 3DO to good use, but all you want is to make the game more like what's promised.

You are obviously entilted to your opinion as always but why not take a stab yourself?

33 minutes ago, Dexiaz said:

 

The hardware. PC is PC, even with 3DO data it will not became the true 3DO Doom with good parameters. It's the emulated version of the game which is not "canon" or "true" or "IDK how you will call it". Just an imitation.

Which is a backport, so it runs natively in the same vein as PsyDoom i believe. So its not really emulated, it just runs the 3DO feature set graphically on PC.

Which is a better carbon copy than recreating it in a modern source port like GZDoom.

Not that projects like DZDoom aren't impressive, mind you. Its just that their root base is vastly different.

2 hours ago, Dexiaz said:

 

I could not be right, but I don't think he meant this. The question is about possibility of the real 3DO hardware to handle Doom in better way than before. Phoenix Doom is good, but it's an imitation like GZDoom PSX TC is imitation of real PSX Doom. BTW, same story with PS1 releases - The Lost Levels for GZDoom PSX TC is not real thing but GEC Master Edition does for PS1 hardware. I suppose @The Strife Commando meant something like 3DO Master Edition version.

 

My answer for his question:

It's possible but only when FPS counter will be slighty fixed. 8 FPS for starting E1M1 room is not good mark, it should be at least 15, because a lot of rooms are just like E1M1 starting room and this is a slideshow. I do remember 3DO's CEL-engine was the reason why FPS is so low - due to wrong rendering of floors and ceilings per second the 3DO hardware spent more power to render it normally. But it's not easy to do something with this, I suppose.

 

But if this problem will be somehow fixed...

I meant if the content that was promised would be added. New weapons, enemies, and levels.

22 minutes ago, Redneckerz said:

Which is a backport, so it runs natively in the same vein as PsyDoom i believe. So its not really emulated, it just runs the 3DO feature set graphically on PC.

Correct - PhoenixDoom is a backport from the 3DO sources and not an emulation. I describe it as a 'remaster' because it seeks to improve greatly on the original without necessarily being very faithful. The renderer is all new for example... My thought process for PD was something along the lines of 'This was a very poor version of Doom, how it can it be made better now that we have the resources and time to do so...' as opposed to PsyDoom which is more like 'This is was a good port, how can it be extended and improved upon while preserving it's essence'. So the philosophies of the two ports differ greatly in terms of what aspects of the original game they seek to preserve. To muddy the waters a little bit though I will add that PsyDoom does include emulation but that is limited strictly to the PSX GPU & SPU in order to help obtain the original look and sound.

Oh, you still don't get my opinion about all of this.

Having Doom 64 Remastered by Nightdive, Phoenix Doom, PsyDoom, etc - is good thing, no doubts. But they are the PC projects. I can't install and run it on native consoles. This is what I want always. To play advanced PSX Doom (by GEC Team) on real PS1, not the ePSXe emulator. And in situation with 3DO Doom, I want to have a chance to play advanced 3DO Doom on 3DO, not the PC. So I have a big interest to help modify the 3DO Doom itself, not PC port.

I hope you'll feel how I see the difference.

On 1/25/2021 at 6:56 PM, Redneckerz said:

The colored lighting puts a heavy strain on the framerate. Is this a limitation of Madam and Clio accelerators (Cel Engine), or is there something else causing this (Like the ARM processor)?

More colored sectors would really add to the total visplanes number. Previously splitting a plane into separate visplanes would happen if height/texture/lighting were different. Now, the RGB coloring and fog effect are added to that (but not the distort as it's just a feedback grid effect if player is inside a sector). In another example, where I randomize RGB colors for every sector, that had some toll to it. Maybe not dramatic, like from 9fps to 7fps or something like that. But in most normal level design, I'd use these effects in few sectors. The way the color RGB works though, is still a CPU manipulation over the CEL palette. The floors are in 8bpp (but really use 32 palette index colors), the flats are 4bpp (16 palette colors). If in the current player view, a visplane about to render (and the nearby walls) have RGB recoloring, I'll call a function to interpolate the colors on the fly (I know, it's realtime manipulation of the colors, but it's all MULs and shifts which are fast on ARM). Color palette numbers are low though so it doesn't waste much. So, performance is not a CEL issue here, it's even more of a visplane splitting issue, lesser realtime palette manipulation issue.

On 1/25/2021 at 4:51 PM, Dexiaz said:

It's possible but only when FPS counter will be slighty fixed. 8 FPS for starting E1M1 room is not good mark, it should be at least 15, because a lot of rooms are just like E1M1 starting room and this is a slideshow. I do remember 3DO's CEL-engine was the reason why FPS is so low - due to wrong rendering of floors and ceilings per second the 3DO hardware spent more power to render it normally. But it's not easy to do something with this, I suppose.

There are still things to do about this, I have a plan, it's just that I didn't started with this and needs more time and motivation, and if I finish and it works without problems (because the lack of CELs texture coordinates will also make this a nightmare) I am not sure if it will save enough at the end. The plan is to strip the whole visplane algorithm process among some other stuff using it (vertical edges for the visplanes, which are also used for sprite clipping, which means I also have to think about what to do with that too) and replace it with a different method, which might be to read the subsectors from the wad as 3d polygons, transform them to the player view and render them using the CEL. It might be hard to pull it off, scrapping the visplanes will gain some frame rate, some of which might be lost later with the new implementation. I'd like to start working on this big part at some point targeted for v0.3, meanwhile I get inspiration for other smaller things like these sector effects (which if I release a version soon, will be for 0.2c. I am also looking at ways to load my own WADs so I could make few extra maps using these effects)

9 minutes ago, Optimus said:

 

More colored sectors would really add to the total visplanes number. Previously splitting a plane into separate visplanes would happen if height/texture/lighting were different. Now, the RGB coloring and fog effect are added to that (but not the distort as it's just a feedback grid effect if player is inside a sector). In another example, where I randomize RGB colors for every sector, that had some toll to it. Maybe not dramatic, like from 9fps to 7fps or something like that. But in most normal level design, I'd use these effects in few sectors. The way the color RGB works though, is still a CPU manipulation over the CEL palette. The floors are in 8bpp (but really use 32 palette index colors), the flats are 4bpp (16 palette colors). If in the current player view, a visplane about to render (and the nearby walls) have RGB recoloring, I'll call a function to interpolate the colors on the fly (I know, it's realtime manipulation of the colors, but it's all MULs and shifts which are fast on ARM). Color palette numbers are low though so it doesn't waste much. So, performance is not a CEL issue here, it's even more of a visplane splitting issue, lesser realtime palette manipulation issue.

:) I like this, similarily to how i like the architecture of the 3DO.

Question time! Optidoom obviously takes into account MADAM and CLIO, but would this also work on 3DO's that had the later revised ANVIL chip, which combines both MADAM and CLIO into one chip? I have read numerous issues arising with it because the layout is not like for like the same.

4 minutes ago, Redneckerz said:

:) I like this, similarily to how i like the architecture of the 3DO.

 

Question time! Optidoom obviously takes into account MADAM and CLIO, but would this also work on 3DO's that had the later revised ANVIL chip, which combines both MADAM and CLIO into one chip? I have read numerous issues arising with it because the layout is not like for like the same.

I've heard someone mentioning this ANVIL chip but I have no idea what is different and if it even affects OptiDoom. Most 3DO software would use the high level API (which Doom also uses, it might use the BurgerLib but last time I checked I think it calls functions on the official API too) and not access the hardware directly. This way, different manufactured 3DOs would not have issues. I heard somewhere, one game Megarace I think, would attempt to do some low level direct hardware access, resulting in not working in some 3DO brand and they had to recall the CDs.

I currently have one PAL Panasonic FZ-1 3DO and also got a Japanese FZ-10, so I will test more and with both 50hz and 60hz. It would be interesting to do some hardware compatibility test. There is an optimization on the wall polygon renderer I did long time ago (that you have to enable from some options as by default the original Doom wall column stretcher (still using the CEL but per column texture individually)) that I had to remove as it worked on emulator but gave 1FPS and black textures on real 3DO (only tested on FZ-1). This had me avoid vertically subdividing the polygons. Originally I only had to do this horizontally, one long wall segment that could be represented with one polygon CEL quad, would have to be split in more quads on X as the texture tiles and CEL doesn't tile (and also not texcoords support). I used a trick for the vertical Y tiling on high walls (the same trick was used for the 1D textures on the original wall column renderer). But it doesn't work with 2D except on emulator. The CEL hardware doesn't like the values I send to make this work. Now, the performance gain is minimal on emulator when I changed the code again, but in few lighter cases are 1-2 more FPS, in other 0.1FPS :). Now that you mention it, I'd like to test this one on the Japanese 3DO again curiously about hardware differences..

This came out from an accidental bug first, but then I thought it's a nice way to combine 1) an expected HOM effect from when there is a missing texture, 2) The screen grid distortion effect I've implemented. It's a feedback sinedistort effect of sorts :)

I'm wondering if that distortion effect could be used to redefine Doom, like Doomguy is under drugs and those zombieman are actually good people fighting back.

Would be cool if the distortion effect happened durimg teleporting. Of course, the teleporting would have to be delayed for 1 second as the player is locked in place, then he gets teleported and locked in place for 0.5 seconds and the he is unlocked and the effect stops.

Or it could be used as a replacement for the endlevel screen melt.

My custom WAD loader works now. This is a basic PWAD loader of maps, it's not going to load additional textures, just the 10 lumps of a MAP (and even will load a megawad with multiple maps, I managed to load FavaBeans episode and finish few levels without problem (but of course with lot's of missing textures as most of the PC Doom resources/texture ids, are missing from the 3DO).

When I test creating my own WADs, I have a special Doom 3DO WAD resources file to load with Doom Builder with only the ones used by 3DO right now. In the future, loading textures would consist of loading the original data from a WAD and map from PC 256 palette colors to the 4bit texture with individual 16bit pal per texture for 3DO walls (and 8bit but with 32 colors palette (only 5bits used) for the flats). It's work for the future but for now I can design my own maps for 3DO or port existing an manually changing all the linedef/sector texture ids.

And here I made a test map where I try all the RGB sector combinations, there is also my fog effect and distort at the end (can be combined). I plan when I release OptiDoom 0.2c to make few maps for fun which I'll also release in the CD, using these effects but also planning on level design that would avoid the performance bottlenecks of the 3DO (fewer visplanes, not many linedefs with upper/lower walls, etc). In the RGB example of course the visplanes at the end hit 64 (regular Doom levels on 3DO side barely ever hit 32, sometimes it's from 2 to 20 in bad cases). I loaded Acheron.wad and hit 32 inside the church from a view. It goes very very slow for the 3DO at that point, so I guess the goal on 3DO before I optimize/rewrite the visplane with something else, is to design levels that try to avoid things that can kill the performance.

Impressive work! Is it possible to check how much of a framerate improvement does switching to low detail mode give immediately, without any other optimizations?

New version is out! This is focused on external WAD loading. Simply throw your wads to the wads folder in the CD, select them from the modmenu and pray they will just not crash :)

I've managed to through oldschool things like Fava Beans there and play through 3-4 maps before the next ones would crash. Then even managed to load Alien Vendetta and maybe MAP01 or 02 would load, very very slow play, crash at some random time. This is a simple WAD loader btw, loads the 10 lumps from the WADs, converts them back to the structure the 3DO expects (32bits for 16bit values, big endian, indices instead of 8 char string for texture IDs, and more), so it's a map loader, not a texture resource loader (for this I'd have to convert the 8bit palette Doom PC textures to the different CEL formats on the 3DO, a work for the future), so when some WADs have texture IDs that don't exist in the limited Doom 3DO resource, I do a manual mapping based on some binary data tables and where with my eyes I matched certain 3DO textures with certain texture IDs in PC Doom 1/2. This way, you can load some maps and things seem consistent even if textures are different. I loaded oldschool stuff like Acheron, Fava Beans (but others like UAC Dead just crashed on me) or even the whole Doom1 or 2 IWAD and things sometimes looked still ok.

Secondly, I did a lot of special fx on the sector types unused bits, like RGB colored sectors, fog effect, warp/scroll floor/ceiling, distort framebuffer when inside sector, etc. I present some test WADs I made with Doom Builder and updated cfg files (which I'll release on a website with tutorial on how to do maps for OptiDoom 3DO specifically), some test maps and one full level using these features as much as it can (but I went overboard with the detail for the 3DO at least and it can drop very low and have freezes because of memory). Lot's of cool stuff there and I have timestamps on the video with the various test maps. Finally, more minor things, fixes, microoptimisations, and 3DO mouse support which is rather good especially if you use the Phoenix emulator which supports it, map the DPAD to WASD, turn up the overclock and enable it, among with always run, mouse slider for speed, etc.

http://bugothecat.net/releases/3DO/optidoom/optidoom_main.html

p.s. I think I'll had my fun with these gimmicks and the loader, I might try to focus exclusively to optimize the engine for 0.3, many people have asked me, some nagged why I do these gimmicks and not focus on optimizing the engine for good in this one. I guess I'll change my direction and focus entirely to that, even though I don't really know when the next version will be out and this one will be done when it's done as it's a daunting task to get some good framerate with this (and more issues to fix like memory hickups/micro freezes).