This is my final project of the year I worked on as far as a new/ remixed game goes: Guwange: OMEN. It can work for both the N64 and Vita, and it also works on the original board too as originally this started out as a rom hack I made earlier in the year. I am demoing this on the @analogue 3D in enhanced mode. The game is based around dodging fields of bullets as opposed to cancelling bullets and eliminating threats quickly, and encourages you to leave as many bullets on the field as possible. The cancellation mechanic is changed to be a local radius of an enemy instead of all frozen ones, so killing enemies does not result necessarily in all bullets being cancelled. Having the skull meter up all the way allows you to perform grazing, and also it activates OMEN X2 mode where you get double the amount of gold you would normally get while grazing. The version also introduces a hitbox on the player so you can maneuver through fields of bullets easier, and there is intentional slowdown in larger fields of bullets. All 3 game modes and rules are available, and in the Vita version, it shows you all the timers, stage map, boss health, etc. as gadgets on the side of the screen. The N64 version can do YOKO 240P and 480i modes as well as TATE modes. The N64 and Vita version saves scores separately across all 3 modes so you can track your progress. You also get access to the original test menu as well. A lot of this port is based on the months of work that went into Batrider: Chase! The backends and engine are the same, just the program is different. I actually enjoyed putting together Batrider: Chase! and OMEN. I am not so much into just porting the game and making it work accurately as opposed to taking a game and making a better experience that I think is good from a game design perspective. I would say this is more work than making a game work accurately in it's original form because you have to ensure balance across the stages, making sure the rules are fair and it's fun, so it forces you to play things a lot more from the player's perspective. I am targeting to release OMEN soon, along with my Analogue Pocket Core which will run the original rom hack version I made earlier in the year. Now that both Chase! and OMEN are gold, with manuals and such produced as well, I will move onto another project that is FPGA based that is brewing.... #CoinOpCollection #CoinOpGameStudio #Guwange #Cave

I like this project! Pretty cool! I am a fan of folks making new experiences for older games as opposed to just porting them to different platforms.

Oh wait, there's another detail that makes this even stranger. The AI bro "B" was the first to implement this FPGA core and release it as open source. The AI bro "A" presumably pointed his AI at his repo and I guess made some improvements. But now the AI bro "B" also wants those improvements, so he pointed his AI at AI bro "A"'s repo and reimplemented them. And now AI bro "A" wants to DMCA AI bro "B" for doing that. Is this not describing open source? Is open source dead then? There seems no point anymore to it. Note, this is a completely true thing that's happening now, and I don't even thing neither I nor AI could craft such a ragebait post. Lol.

Soo... There's a weird and funny situation that came across my desk today, won't say who it is or anything... So there's a guy who created an FPGA core from MAME via AI, and posted it as open source. There's now a different bro, also using AI to create FPGA cores who I guess pointed his AI at the other guy's repo and reimplemented it. And AI bro "A" is trying to DMCA AI bro "B"? Like how does it work? Legal minds anywhere? LOL. This timeline is very weird.

I managed to get a black SNT+... but man that captcha was EVIL.

I don't know what everyone is talking about, but the N64 is extremely powerful, a lot more powerful than I thought it was prior to a few months ago when I started working with it. Especially with @analogue 's overclocked modes in the A3D, you can really do some magical things on the N64 due to the high and fast memory I/O. I recently discovered the 480i modes!! I have a couple projects I have been working on the past few months during my break from FPGA projects that I will release soon... stay TUNED. #CoinOpCollection #N64

Next and finally in the technical posts on the architecture of Batrider Chase!: the PS3 version. The PS3 runs the same C++ game core as the Vita version: the decompiled game rebuilt from the Ghidra project, with Chase! Mode, the menus and the extra features on top. The Cell processor is a very different machine from the Vita. It has one general-purpose PowerPC core (the PPU) with two hardware threads, plus six SPUs available to games. Each SPU is a fast vector processor with its own 256 KB of local memory. The RSX is the GPU. The first build ran everything on the PPU and was far too slow on a real console, so the work was spread out: the PPU runs the game, and the SPUs do the drawing. Below is the PS3 version diagram. Sound: Like the Vita, the PS3 runs the original sound board with nothing pre-rendered: the Z80 sound program, the YM2151, and both 6295s playing the original ADPCM samples from the sound ROMs. With the whole board on the game's thread, the game ran in slow motion, so the board is split across the PPU's two hardware threads. The game thread runs the Z80 and the chips' timing right alongside the main program, since the two talk to each other constantly, and writes down every chip write with the exact sample it happened on. A second YM2151 and pair of 6295s on the synth thread replay those writes and generate the waveforms. The output is bit-identical to running the whole board in one place. The synth thread has the highest priority on the system. It feeds 48 kHz stereo to the PS3's audio out and keeps 100–150 ms queued, so the sound holds steady through the busiest scenes. Graphics: The tile data is the original ROM, untouched, and stays in main memory. Every frame, the PPU splits the 320x240 picture into five bands of 48 rows and hands one to each of five SPUs. Each SPU pulls in the frame's sprite and tilemap state, then fetches the 8x8 tiles it needs into a 1,024-tile cache in its local memory. It draws its band in the arcade's own priority order: the backdrop, the three tilemap layers and the sprites across 16 priority levels, then the text layer. Flips and mirrors are handled as each tile row is drawn. Each SPU then sends back its band turned upright, plus a priority map the hitbox uses. It also sends its share of the final picture at 3x size, with scanlines added when they're on. The SPUs' picture is pixel-identical to the reference renderer, and 60 frames of every play session are checked against it. On a real console, drawing the picture used to take about 7.5 ms of every frame on the PPU. The SPUs now do it in parallel. The sixth SPU scales the Chase! gadget panels, which are composed in spare PPU time a few times a second. The PPU lays the Chase! overlay and the hitbox on top. The RSX doesn't run a single shader. Its transfer engine scales the finished picture to the TV at 720p or 1080p, places the gadget columns down each side, and flips on vsync. TATE mode turns the whole screen for a TV on its side, with the gadget panels moved to strips at the top and bottom. So the PPU's threads run the main program, the sound, the screen and the gadget panels, and the SPUs and RSX handle all of the drawing. The game never waits on the picture: if a frame isn't drawn in time it's skipped, and the game and sound keep running at the arcade's 59.6 Hz. #CoinOpGameStudio #Batrider #Raizing #PS3

Next in the technical posts on the architecture of Batrider Chase!: the PS Vita version. The Vita runs the same C++ game core as the PS3 version: the decompiled game rebuilt from the Ghidra project, with Chase! Mode, the menus and the extra features on top. The Vita has a quad-core ARM Cortex-A9 at 444 MHz, three cores of which are available to games, and an SGX543MP4+ GPU. So the work here was giving each core its own job and moving the drawing onto the GPU, which runs at its full 222 MHz. Below is the Vita version diagram. Sound: Unlike the N64, nothing is pre-rendered. The Vita runs the original sound board: the Z80 sound program, the YM2151, and both 6295s playing the original ADPCM samples straight from the sound ROMs. To make it fit, the board is split across two cores. The main program and the sound CPU talk to each other constantly, so core 0 runs the Z80 and the chips' timing right alongside the game. It writes down every chip write with the exact sample it happened on. Core 2 has a second YM2151 and pair of 6295s that replay those writes and do the heavy part, generating the waveforms. The output is bit-identical to running the whole board on one core. A feeder thread on core 2 sends 48 kHz stereo to the audio out and keeps 100–150 ms queued, so a busy scene never breaks up the sound. Graphics: The tile data is the original ROM, untouched. On the first frame, every 8x8 tile is repacked into 4-bit paletted textures in video memory: 32 pages of 1024x1024, 16 MB. Each of the game's color banks becomes a 16-colour palette. Every frame, core 1 builds a draw list in the arcade's own priority order: the backdrop, the three tilemap layers and the sprites across 16 priority levels, then the text layer. That's 600 to 1,900 textured quads in 10 to 70 draw calls, which the GPU renders into a 320x240 picture. Flips and mirrors cost nothing here because the GPU just swaps texture coordinates, and neighboring tiles of a sprite go out as a single quad. A palette that changes goes into a fresh slot in a ring of 16,384, so color cycling stays exact even while the GPU is still drawing the previous frame. The GPU then draws the whole screen: the game turned upright and scaled to full height, the Chase! gadget panels down each side, and the wallpaper behind. The gadget panels are composed in spare CPU time a few times a second, and only the rows that changed are uploaded. To keep the GPU's picture pixel-perfect, a low-priority thread redraws every 20th frame on the CPU and compares the two pixel for pixel. If they ever disagree three times, the game switches to CPU drawing for good. So core 0 runs the main program, core 1 builds the screen, and core 2 handles the sound. The gadget panels and the picture check fill spare time on cores 0 and 1. The game never waits on the picture: if a frame isn't drawn in time it's skipped, and the game and sound keep running at the arcade's 59.6 Hz. #CoinOpGameStudio #Batrider #Raizing #PSVita

This is a start of a few technical posts on the architecture of Batrider Chase! The game is extremely intensive and requires a great deal of processing power for the Sprite engine, calculations and graphics. Therefore, it was important to take the different pieces of work, and distribute them effectively across the resources of the respective systems. Below is the N64 version diagram. As mentioned before, the game was decompiled and a Ghidra project was run over the course of a few months rebuilding the game in C++. Once the base game was built and verified completely, the Chase! Mode was developed and the menu system and extra features. Sound: The N64 version has the music pre-rendered and converted into a mono IMA format at 22.05khz. The sound effects are mostly the original ADPCM data but also in IMA format. A custom sound driver was written to stream the audio data from the cart, and the main program has direct requests to the sound driver. There's no emulation of the ym2151, z80 or 6295 anywhere here. Graphics: Mostly the original data, but reordered in a way such that each 8x8 tile is 32 bytes contiguous (interleaved, row major). The engine calls for 8x8 tiles, and the RDP draws them as textured cells. There is caching implemented, and it's very critical to improve performance on mirrors/flips and so on that happen throughout the game. So for intense scenes and particle effects, you can have hundreds of textured tiles all flying back and forth along with the ships and other background effects, and so on. The RSP plays a critical role in determining the drawing commands that the RDP uses to render the picture, and it also performs mixing of the sound. The CPU runs the main program and sound driver that sends the work to the RSP, like the draw lists, sound commands, etc. The audio mix goes directly out and the RDP takes the intermediate commands the RSP makes and draws the final frame composition. #CoinOpGameStudio #Batrider #Raizing

This is a start of a few technical posts on the architecture of Batrider Chase! The game is extremely intensive and requires a great deal of processing power for the Sprite engine, calculations and graphics. Therefore, it was important to take the different pieces of work, and distribute them effectively across the resources of the respective systems. Below is the N64 version diagram. As mentioned before, the game was decompiled and a Ghidra project was run over the course of a few months rebuilding the game in C++. Once the base game was built and verified completely, the Chase! Mode was developed and the menu system and extra features. Sound: The N64 version has the music pre-rendered and converted into a mono IMA format at 22.05khz. The sound effects are mostly the original ADPCM data but also in IMA format. A custom sound driver was written to stream the audio data from the cart, and the main program has direct requests to the sound driver. There's no emulation of the ym2151, z80 or 6295 anywhere here. Graphics: Mostly the original data, but reordered in a way such that each 8x8 tile is 32 bytes contiguous (interleaved, row major). The engine calls for 8x8 tiles, and the RDP draws them as textured cells. There is caching implemented, and it's very critical to improve performance on mirrors/flips and so on that happen throughout the game. So for intense scenes and particle effects, you can have hundreds of textured tiles all flying back and forth along with the ships and other background effects, and so on. The RSP plays a critical role in determining the drawing commands that the RDP uses to render the picture, and it also performs mixing of the sound. The CPU runs the main program and sound driver that sends the work to the RSP, like the draw lists, sound commands, etc. The audio mix goes directly out and the RDP takes the intermediate commands the RSP makes and draws the final frame composition.

Analogue hitting on all cylinders as of late!

Batrider Chase! Gameplay test (N64) This video shows the basic mechanics of the game like the Chase! chain multiplier, medaling and Chase! Break mechanic where you can cancel the bullets on screen for medals. Also demonstrates the high level of difficulty. youtu.be/NCPlPBTML0o

Here is the most interesting version of Batrider Chase! - the N64 version. This version was a pain to get working at the right speeds and involves careful balancing of the work between the main CPU and the RSP/RDP. The sprites and particle effects are fully retained as well as all the Chase! mechanics and original game mode. No gadgets, however, in this version and it only operates in tate mode. This was captured on a regular N64 with the ultra HDMI mod with expansion pak and summercart 64. There is saving support to eeprom for high scores and menu options. So this rounds out the versions of the game I showed: PC, PS3, Vita and now N64. I had a Saturn version I was testing but it did not meet benchmarks for speed and performance that I was looking for, so that is on hold. Overall, this project was interesting. I have been doing emulation and reverse engineering projects for more than 20 years and this is my first time actually doing a decompile approach. I found it interesting and different because I could essentially take the different components of the game work-wise and distribute them more efficiently for a target system once I have a common core backend (C++ in this case). With emulation, I can't deconstruct the game logic and have some of it run on one thing and other parts of it running somewhere else, and I also cant control how the program uses the memory and rewrite the logic. So, I think I like the decompiled approach specifically for making games work on consoles and embedded systems and it allows me to choose the appropriate mechanism and distribution of load efficiently depending on what I am working with. So, this method I think has the biggest payoff in terms of flexibility, but it is also very time consuming. Just to run the whole Ghidra project and verify everything at the first level took months, and then creating the different wrappers for the different platforms and features and such took another couple months. I am astonished it works on the N64, Vita and PS3 though, and very happy with the end result. Will I do another one of these again? I don't know, primarily I did this for learning purposes and I did learn a lot of things while doing this, but unsure if I will do another one of these again. The legality of distributing these is also another pain point, its not like you just tell people to bring their roms and that's it, the data formats are all custom and a lot of the code is rewritten, and there is a mix of different things so it's a bit hard to really "convert" the graphic and sound data I need from the original rom cleanly into a distributable package. I will have to research it. Until then, it remains internal. #CoinOpCollection #Batrider #N64

This is the PS3 version I am showing you now. The challenges in making this version are discussed in the video, but primarily it was distributing load between the RSX and main CPU. The main CPU didn't have enough power to run the sprite engine, so I have that in the RSX of the PS3. The sprite engine is highly complex in the game, like there are velocities and particle effects that get calculated per frame and for the complex boss attacks and phases and such, so everything has to keep up for all the bullets and stuff on screen.

Following yesterday's short demo, today I am showing you the PSVita version of Chase. I like this better because the CPU behaves to my liking and achieves slowdowns properly in heavy areas, and it's my favorite version to play. I received some messages yesterday in terms of ideas towards a legal pathway to make this available. Obviously it's a free game, but I would have to share it in such a way to not breach copyrights. So still currently researching a legal pathway to make this available.

This is a short demo of something I worked on for the past few months on and off and more during the summer when I was travelling without access to my computer: youtube.com/watch?v=QDetNkc6… It's a remaster/ remix of Batrider called Batrider Chase! It does not use emulation at all, it started out as a decompilation effort and then transitioned into a reimplementation effort. I replaced the sound and graphics drivers too, and made the music stereo instead of the mono on the original board. There is also an option for custom soundtracks and redbook audio I intended to get to, but didn't. The backend is C++ and it is multiplatform. It works on N64 and Saturn (some frame drops due to the limits of the system) and it also works on PC, Vita and PS3 (Full game with gadgets). I did this project primarily for learning purposes to learn about decompilation projects. Having gone through the exercise, I did not see a legal pathway to releasing this, so it remained and still remains internal and amongst friends.