Idea for a 2D port: Oddworld Abe's Oddysee using R.E.L.I.V.E. engine?

I honestly wasn't trying to put you down. it's just really frustrating that the answer of "how many palettes can the Saturn do" is such a simple thing to actually find out, no need for guessing of burning tokens to get an answer that is completely wrong. And now you know for sure, because I explained it. Good luck with your project.
@nando:
Yes, don't get me wrong, I was mostly frustrated by myself other than something else.
I meant it when I said I needed a good night of sleep and a proper look on it. I should take the time to investigate and find the real problem and solution.
I had to leave for my flight and I knew I would have no more access to my Saturn for over a month, so I tried to finish up too many things at the same time, which only had very poor results because of the way I did it. I will do better next time (and more importantly, will verify what I write here if it was originated by an AI).
My bad on that, thanks again for caring enough to reply and correct my mistakes.
 
Last edited:
@nando:
Yes, don't get me wrong, I was mostly frustrated by myself other than something else.
I meant it when I said I needed a good night of sleep and a proper look on it. I should take the time to investigate and find the real problem and solution.
I had to leave for my flight and I knew I would have no more access to my Saturn for over a month, so I tried to finish up too many things at the same time, which only had very poor results because of the way I did it. I will do better next time (and more importantly, will verify what I write here if it was originated by an AI).
My bad on that, thanks again for caring enough to reply and correct my mistakes.
If you have questions that seem like they should have obvious answers, honestly just ask. There is discord too, and Saturn has halfway decent documentation. VDP2 is the most complicated (almost 500 pages) but if you know what the question is, you can probably find the answer there. The exception being that the descriptions are not always straight forward or easy to understand 😀
 
If you have questions that seem like they should have obvious answers, honestly just ask. There is discord too, and Saturn has halfway decent documentation. VDP2 is the most complicated (almost 500 pages) but if you know what the question is, you can probably find the answer there. The exception being that the descriptions are not always straight forward or easy to understand 😀
Yes, I'm on the discord also, and have the official sega saturn developer cd iso mounted on my computer.
Honestly I have zero excuse not to look it up.
The problem was more about knowing what to look for in this situation, and the final rush to get my plane. But hey, lesson learned. Thanks.
It also seems that I was looking in the wrong direction the entire time, as there are plenty animation / textures poorly converted / stored in the current version, such as shadows for example. Clearly needs some tuning. Carlos point was still helpful and helped me sort out one of the issue.
I'll list, investigate and solve them one by one when I have the time to.
 
Hi guys, I've been wrapping my head around the CRAM issue and the stuttering, and I think that we could look at it from a mixed 4-BPP/8-BPP pipeline perspective combined with a very surgical use of the SCU-DMA for key triggers.
Abe and the main backgrounds definitely need 8-BPP, but maybe we can crunch all secondary assets down to 4-BPP. Stuff like shadows, portal effects, or explosions could easily live in 16 colors with some good old-school dithering, saving a massive amount of palette banks.
As for the SCU-DMA, instead of triggering transfers chaotically, we could restrict its scope to four precise scenarios:
1-SCU DMA Level 0 bursts used exclusively during flip-screen transitions, dumping the background from Work RAM to the VDP2 VRAM (inactive layer) right before Abe hits the screen boundary.
2-Handling Abe's heavy action states via sprite streaming into the VDP1 VRAM during V-blank, so we don't clog the memory with all his frames at once.
3-Mirroring the VDP1 command tables in Work RAM High and performing an indirect DMA transfer per frame to VRAM, keeping both SH-2 cores completely free for AI and collision checks.
4-And for the palette overlapping, updating color data directly from Work RAM to the CRAM palette banks using DMA synced with V-blank.
Sounds like a hot take and a lot of asset management on the PC side first, but maybe it's a viable way to bypass the hardware limits. What do you guys think?
 
I'll check that, thanks. The palette overlapping is fixed, and so are most animations (no more black and white corruption).
I still have to fix the moving barrel rectangle animations, and implement some shadows with saturn hardware (right now, they're 8bpp and using ram space for nothing, just dumbly converted from original format), then I'll see how to optimize everything, ease up ram usage, and adding up the audio.
 
I'll check that, thanks. The palette overlapping is fixed, and so are most animations (no more black and white corruption).
I still have to fix the moving barrel rectangle animations, and implement some shadows with saturn hardware (right now, they're 8bpp and using ram space for nothing, just dumbly converted from original format), then I'll see how to optimize everything, ease up ram usage, and adding up the audio.
Hi N0rt0N85,
That’s fantastic news! Hearing that you already fixed the palette overlapping and the black and white animation corruption is amazing. You are ironing out those bugs fast even while traveling! Handling the shadows natively through Saturn’s hardware instead of wasting RAM with raw 8bpp conversions is definitely the right call, it will free up so much headroom for the upcoming audio engine.
I'm working on a setup right now where I have my raw videos in uncompressed .avi, alongside the audios, backgrounds, and sprites already converted into Saturn-compliant formats for my first level. I would love to send these files over to you via Google Drive if they can help you with your asset testing and pipeline development! Seeing how you map out the RAM tiers is pure gold, as I'm facing those exact same file management challenges at the moment.
Please keep up the amazing work! Enjoy the rest of your trip in August, and we’ll be right here eagerly waiting to see how this engine behaves on real hardware at the end of the month. History is being fixed right here.
Cheers from Spain, you are an absolute crack!
 

What's new since July 20​

Colors finally behave (July 21–27)​

The Saturn has very little dedicated color memory, and for weeks characters and objects had been stealing each other's palettes: Mudokons flashing wrong colors, levers turning odd shades, elevator barrels going dark.
  • Every recurring character in the first level fits into a tiny shared color budget with zero quality loss, so Abe, the Mudokons and the Sligs now get permanently reserved color slots, their colors are correct and stable instead of fighting for space (the idea suggested by @carlos24_).
  • Objects like levers and props no longer inherit the colors of whatever was on screen before them.
  • Background animations (the elevator chain and platform) no longer flash black and white.
  • The elevator barrels got their real colors back: the game was guessing how many colors each image needed and guessing wrong, so the barrels shared a palette with the pull-rope and lost. Now the game measures what each image actually uses.

Cleaner screen transitions (July 29)​

When walking from one screen to the next, leftover foreground scenery from the previous screen used to hang on the screen until the new one finished loading. It's now wiped instantly the moment the transition starts.

Real shadows (July 29–31)​

Characters' shadows had been drawn as solid dark blobs, all the same size.
  • First pass: a checkerboard-dither trick made them roughly 50% see-through, but it looked ugly.
  • Final version: the shadows now use a native Saturn hardware feature (VDP2 shadow function) that genuinely darkens the background beneath them: smooth, truly translucent, and costing essentially nothing in performance. They also scale properly: a Slig's shadow matches a Slig, shadows shrink as you jump, and they clip correctly at ledge edges, just like on the PlayStation.

The sideways-Mudokon glitch (July 29)​

Mudokons facing back would visibly jitter a few pixels sideways off their shadow. Cause: when the Saturn mirrors a sprite, some invisible padding pixels got mirrored to the wrong side, pushing the character over. Flipped sprites are now anchored from the other edge, so characters sit exactly on their shadows in both directions.

️ Crash-proofing (July 31)​

Wesker's real console crashed after ~51 minutes of play. The cause was tracked down from a photo of the crash screen: the engine occasionally asks an animation for a frame that no longer exists in memory, and one unguarded path let that kill the whole machine. Two fixes:
  • Any bad animation frame now safely disappears for a single frame instead of crashing the console.
  • A memory bookkeeping bug (a "freed but not forgotten" buffer that could silently corrupt other data) was closed.

More characters on screen, no more tearing (Aug 1–2)​

The biggest fix of the period. Two long-standing complaints: Abe's sprite visibly tearing when animations change, and sprites vanishing on busy screens (like the lower elevator room), fell together after a deep audit of the Saturn's sprite library:
  • It turned out the system had been silently deleting any sprite past the 40th, and deleting the closest ones first, which is exactly Abe and the enemies. The limit is now 60, with the underlying memory laid out the way the hardware manual actually requires (the old layout was quietly corrupting itself past 43 sprites, the real cause of an older mystery crash).
  • The tearing happened because the game sometimes redraws a character's image twice in the same tick, and the second redraw landed on the exact image the hardware was still busy displaying. Fixed: confirmed gone by eye and by counters (178 tear events per session → 2).
  • Along the way, ~4 KB of scarce memory was reclaimed by measuring (rather than assuming) how much a legacy reserve actually needed: the answer was zero.
Still to fix: the elevator chain is not optimized and continues to glitch.

SOUND IS ON (Aug 3)​

The port is no longer silent: sound effects and music now actually play (confirmed in the emulator). This was the biggest missing piece of the whole project.
  • The Saturn's dedicated sound chip is now driven directly, with all 32 of its voices mapped to the game's audio engine, including the same voice-recycling logic the original game used, so busy scenes steal the least important sound, not a random one.
  • All the game's audio samples are converted offline into the Saturn's native format. The sound bank for the first level squeezes into the chip's tiny memory (99.7% full!) with a trick: every voice line is kept 100% untouched, while less critical effects are gently downsampled with a proper filter so they still sound clean.
  • The music clock now ticks, which means the game's adaptive soundtrack works. The music can react to what's happening on screen, like on PlayStation.
  • The pitch math was rewritten for the Saturn's CPU (which has no floating-point unit): note pitches are now computed with fast integer math accurate to less than 1/100th of a semitone.
  • Three independent reviews of the code caught and fixed a batch of subtle bugs before they could ever be heard: sounds getting cut short after pitch changes, a slow memory leak in the sound chip's RAM, a screeching tail when a voice was stolen, and a rare race condition at startup.

Again, thanks @slygamer, @Wesker for the hardware tests and @carlos24_ for ideas and emulator tests.

My attempts to create native proper lightings failed so far (green and orange lights on platforms and doors, for example), and still plenty of bugs to go, but I'm happy with the progress.
 
Last edited:
Back
Top