Paprium - New beat em' up for MegaDrive/Genesis

[Udderdude]

Best footage I've found thus far: https://sendvid.com/9i700baa

A bit more flattering than the previous vid. I don't see any teleporting grabs this time. But it still looks pretty jank and everything just lacks any sort of weight or impact. The AI also seems kinda lackluster.

(Yes, I am factoring in the fact that this thing was in development for 8 friggin' years.)

[BIL]

Rad, it seems choosing the grappler gets you Iron Commando and the middleweight Sonic Blast Man That's a quarter of a beater and half another for the price of one!

Surprise 1000/10 for BK3 Ash-alike () named Rutubo ()

[Udderdude]

Ok, we got one more video here. Of course, it's still someone filming a TV .. lol. This one has the female character. She's fast as fuck and honestly looks better designed and programmed than the other two. https://www.youtube.com/watch?v=xIKPV2xcw2M

[BIL]

Gives quite a different impression, looks like a competent SFC beltscroller in that footage. That's not a backhanded compliment, I own and love many such examples. By comparison BIGDUD looks an incompetent SFC beater. Almost looks like an earlier build.

[Stevens]

Yeah like she got the extra animation frames.

[Sumez]

Also revealed: DER DATENMEISTER. Wonder what's under the lid there? Certainly doesn't even look like a Genesis game anymore.

https://imgur.com/a/rvKb0pP

Lol what the hell!
So it turns out it's not even a MegaDrive game? What a god damn scam!

Sure, in the early 90s you could release a game running entirely on an in-cart co-processor and market it as a Sega game as long as you could plug it into the console and play it - who cares, you get to play the game, that's all that matters.
But releasing a game "to celebrate the 30th anniversary of the MegaDrive" and it's not even a MegaDrive game? That's hilarious.

68K assembly isn't exactly rocket science, it's one of the friendliest assembly languages to work with, and it shouldn't pe awfully hard to do it legit. And if that fails, you can actually do C compilation for it with very little damaging overhead.

Best footage I've found thus far: https://sendvid.com/9i700baa

This doesn't look anywhere near as bad as the first one. It actually looks somewhat decent with the caveat of obvious jank.

[Udderdude]

All we know for sure is there's at least an audio co-processor under the hood.

Finally, some actual direct capture footage that's an hour long, played with the female character. https://www.youtube.com/watch?v=cJQqHTqdNV8

[MintyTheCat]

Wow, I never realized the Genesis had so many hardware revision compatibility problems. Wasn't aware the 6 button controller actually refuses to work with certain games.

The 6 button pad I have has a mode to select 3 or 6 button mode.
It's really only some of the very early model 1 machines that have issues. There may be a few with the MD3 and the Nomad but I cannot recall

[Stevens]

All we know for sure is there's at least an audio co-processor under the hood.

Finally, some actual direct capture footage that's an hour long, played with the female character. https://www.youtube.com/watch?v=cJQqHTqdNV8

Well that looks a fair bit better.

Thoughts from just watching a few minutes of each stage -

Enemy variety is ok.

Game feels like one long stage, but not enough variety in backgrounds for the most part.

I'm glad people got their game though!

[Sumez]

.... does the text under the Paprium logo in the background grafiti actually say "Keep waiting"?

[BIL]

"Keep faith" I think. I wondered at first if the cross was meant to resemble a Konami logo and nodded agreeably. Yes, random homebrew guys, I am indeed keeping faith for Arcade Archives: Violent Storm!

[orange808]

Lol what the hell!
So it turns out it's not even a MegaDrive game? What a god damn scam!

Sure, in the early 90s you could release a game running entirely on an in-cart co-processor and market it as a Sega game as long as you could plug it into the console and play it - who cares, you get to play the game, that's all that matters.
But releasing a game "to celebrate the 30th anniversary of the MegaDrive" and it's not even a MegaDrive game? That's hilarious.

68K assembly isn't exactly rocket science, it's one of the friendliest assembly languages to work with, and it shouldn't pe awfully hard to do it legit. And if that fails, you can actually do C compilation for it with very little damaging overhead.
.

lmao
Well, I look forward to your upcoming game release that does it "right".
lmao

You're wrong and here's why:

Given the rich history of adding enhancement hardware to carts, you sound pretentious and obtuse, here. Of course new games should have significant hardware upgrades in the carts. It's almost 2021! Moore's Law and whatnot.

First of all:
The MD/Genny already has tons of 1990's era tech games. Why make another one? Shouldn't we push things forward?

Next:
I also don't understand why you're only comparing the cart hardware to the glory days. There's more to the story. What about the development process? Is that different for new games on an old platform? (Yes, it is.)

This is a homebrew from a small team and it won't make a penny of real profit. The professional dev teams in the MD/Genny era had a huge advantage over indies in 2021. They had time, paychecks, and a team of specialists.

No homebrew team has the kind of resources a real software house could pour into a AAA release back in the nineties, yet their work will be judged against those games (despite the large dev teams and money those old games got). So, it makes sense that the cart would have enhancements to steamline development. There's a strong chance the cart's enhancements help reduce the dev's workload--while, simultaneously, providing more bells and whistles.

Successful homebrews are expected to push the platform forward with significantly fewer resources (and rewards). That's why the cart is enhanced and I don't see the problem.

Finally:
There's a serious piracy issue with homebrew roms. Everyone thinks new games on old systems should be free (because the legacy library is warez). Even Mr. Closed Source FPGA guy thought it was cool to release all the details on how to play a brand new rom on the ColecoVision, because DRM be so "unfair" (but MiSTer can't run his cores. That's different.). Yeah, fuckin whatever, dude.

But, I digress... The add on chips keep you from running a dumped rom, so the devs can recoup a few dollars/euro/quid on their hours of labor. That's a fair request.

[Sumez]

First of all:
The MD/Genny already has tons of 1990's era tech games. Why make another one? Shouldn't we push things forward?

Sure, but making a game on MegaDrive is hardly "pushing things forward", and that's obviously not the intention with a release such as this.
My post was exlusively directed at the discussed assumption that the thing on the PCB was some kind of FPGA, MCU, or essentially a coprocessor running game logic, which would mean the program that makes up the game essentially isn't a MegaDrive game, but a game designed for that hardware instead.
For a game that's specifically marketed as a celebration of the MegaDrive, don't you think there's at least some kind of irony to that?

Using tech to make consoles do things they weren't normally capable of is interesting. I'm personally interested in that stuff. But it's a very different thing from making a homebrew game specific to that platform.
I won't pass judgment entirely until I know what that thing in the cartridge is doing, because it really could be anything. But if we're assuming it's a coprocessor, and it is doing game logic, then what you are seeing on your MegaDrive suddenly has very little to do with what the MegaDrive is capable of.
Cartridges are cool because you can put all kinds of stuff in them. And if it's some kind of weirdly advanced mapper chip, then that's fair to some degree. But that thing looks like massive overkill for rom mapping purposes. I'm curious to hear if it's actually some kind of genuinely cool thing.

This is a homebrew from a small team and it won't make a penny of real profit. The professional dev teams in the MD/Genny era had a huge advantage over indies in 2021. They had time, paychecks, and a team of specialists.

You're wrong, and here's why:

In fact, you said it yourself. Modern homebrewers have a lot of advantages over professional development teams of the era. Not only do we have decades of research, documentation and reverse engineering to look back on, we have much better tools and resources available. Emulators, debuggers, and even helpful utilities to create and convert artwork that are still improving to this day.
And finally, we have a lot more time. Most MegaDrive games were churned out in half a year.
Paprium took eight years.

Paprium took eight years.

If you're claiming the people behind Paprium "won't make a penny of profit" I think you have a lot of research to look into.

Successful homebrews are expected to push the platform forward with significantly fewer resources (and rewards). That's why the cart is enhanced and I don't see the problem.

I'm not sure what the point is, or how the above makes sense. How does "enhancing the cartridge" relate to the resources available to the developer?
Are they able to make a game using fewer resources due to a coprocessor in the cartridge? In what way? You still need to create everything that makes up the game, including game design, engine, stages, and lots of graphics and animations, etc. The amount of resources are still the same.

[BareKnuckleRoo]

Sure, in the early 90s you could release a game running entirely on an in-cart co-processor and market it as a Sega game as long as you could plug it into the console and play it - who cares, you get to play the game, that's all that matters.

How many games were released like that for the NES/Genesis/SNES out of curiosity? The closest I can think of are something like the Super FX games on the SNES that basically enabled graphics the SNES wasn't natively capable of, but as far as I know the SNES itself was still handling a lot of the processing ?

[Sumez]

Finally:
There's a serious piracy issue with homebrew roms.

The massive success of people selling literally just ROM files tells otherwise.
If you want people to not pirate your game, just make it easier for them to not pirate it.

But that is really a completely different subject. Paprium was based largely on crowdfunding, and I doubt whatever this is was intended as an anti-piracy measure. At least not primarily.

[Sumez]

How many games were released like that for the NES/Genesis/SNES out of curiosity? The closest I can think of are something like the Super FX games on the SNES that basically enabled graphics the SNES wasn't natively capable of, but as far as I know the SNES itself was still handling a lot of the processing ?

It depends on your definition I guess, because lots of games have helpful chips inside their cartridges - almost every NES game has at least mapper functionality, and one of the most common ones also has a scanline counter which added more "features" you wouldn't be able to do on a stock NES. But it's so common that it's almost expected that NES games have that ability.
SNES games have a huge variety of custom chips, most often used for data management, like graphics decompression and such, to save ROM space (something that wouldn't be an issue to modern developers).
Custom chips in MegaDrive cartridges are less common to my knowledge, but a really obvious example would be Virtua Racing.

Similar to that, the SuperFX is probably one of the more popular examples when it comes to stuff that the stock console obviously wouldn't be able to do on its own. It's a chip designed specifically to excel at complex math that allows 3D transformations - same basic idea as what you're seeing in modern PC GPUs, but obviously a lot more primitive. I don't think it has much practical usage outside of rendering graphics on the fly - it's not like it's just a cheap way of speeding up the SNES.
Even then though, the subject has been discussed many times before. Is a SuperFX game "a SNES game", and if not, where do you draw the line in terms of custom chips?
The banger here is that you could put a raspberry pi running a raspberry pi program in an NES cartridge, and output the graphics directly on the "CHR data" lines (the graphics ROM). You'd need to include a small NES program to make sure those graphics get displayed on the console, but outside of that everything else is on the Pi. Would that still be "an NES game"?

Obviously, at least at the time licensed games were released it didn't matter. If it's a game you can play by plugging it into your SNES/MD, it's a SNES/MD game, right? That's all you'd need to care about.
But in terms of retro homebrew, the entire idea is limiting yourself to a certain hardware definition, so some kind of well defined constraint makes sense. It's a commonly discussed subject, and at the end of the day, people are allowed to make whatever they think is fun to make. But I'd expect them to at least be up front about their product.

[orange808]

First of all:
The MD/Genny already has tons of 1990's era tech games. Why make another one? Shouldn't we push things forward?

Sure, but making a game on MegaDrive is hardly "pushing things forward", and that's obviously not the intention with a release such as this.
My post was exlusively directed at the discussed assumption that the thing on the PCB was some kind of FPGA, MCU, or essentially a coprocessor running game logic, which would mean the program that makes up the game essentially isn't a MegaDrive game, but a game designed for that hardware instead.
For a game that's specifically marketed as a celebration of the MegaDrive, don't you think there's at least some kind of irony to that?

No. If the Mega Drive was still alive, devs would competing and using any enhancements they could find. I see innovation--and you can't call it dead if there's still innovations rolling out. I don't see irony. I see, "I ain't dead yet, muthafucka."

It's still progress, because pushing things forward on the platform itself is progress. Obviously, the hardware presents limits that cannot be overcome, but that's the point. The MD/Genesis has a unique charm.

It doesn't make a damn bit of difference if the coprocessor handles some logic. Looking at the video, the cart is still using the MD/Genny hardware for visuals and sound duties. Furthermore, the ability to offload logic to a coprocessor wasn't unprecedented in the 16 bit era. Super FX and SA-1 allowed it. (I guess you could go all "console wars" and make it a Sega vs. Nintendo thing. Be my guest, there. Won't change a thing.)

It's just a faster coprocessor. That's unsurprising, because it's almost 2021.

Using tech to make consoles do things they weren't normally capable of is interesting. I'm personally interested in that stuff. But it's a very different thing from making a homebrew game specific to that platform.

Star Fox. *Drops mic.*

In fact, you said it yourself. Modern homebrewers have a lot of advantages over professional development teams of the era.

No. I didn't. I said the opposite. I did say the devs innovated and used modern technology to level the playing field between their small team and large team of professionals that got paid.

Not only do we have decades of research, documentation and reverse engineering to look back on, we have much better tools and resources available. Emulators, debuggers, and even helpful utilities to create and convert artwork that are still improving to this day.
And finally, we have a lot more time. Most MegaDrive games were churned out in half a year.
Paprium took eight years.

Paprium took eight years.

Yes. It took eight years because nobody is getting paid. That's hundreds of hours of work. Have you ever worked on a dev team? Yes, I have.

Sega's in-house programmers knew the hardware intimately and they did a good job teasing out the machine's abilities. The only platform I know of that makes a quantum leap with modern documentation is the Atari 2600.

If you're claiming the people behind Paprium "won't make a penny of profit" I think you have a lot of research to look up on.

You won't recoup hundreds of hours of work. Paying me pennies an hour isn't a real profit. It's a labor of love. Between the software and hardware design, I can't imagine how much time and energy they have invested.

Successful homebrews are expected to push the platform forward with significantly fewer resources (and rewards). That's why the cart is enhanced and I don't see the problem.

I'm not sure what the point is, or how the above makes sense. How does "enhancing the cartridge" relate to the resources available to the developer?
Are they able to make a game using fewer resources due to a coprocessor in the cartridge? In what way? You still need to create everything that makes up the game, including game design, engine, stages, and lots of graphics and animations, etc. The amount of resources are still the same.

One scenerio is an ARM processor. The ARM would feed instructions (and a ton of no ops to the MD hardware registers). The ARM would "race" the Mega Drive. Because the ARM runs faster than the Mega Drive, the slack time (between sending updates to the Mega Drive and during no-ops) would be available for logic. Additionally, the game's state would "live" on the ARM cart. That allows a large share of the game to be written in C++. That makes development (writing, debugging, and iterating) significantly easier.

[BareKnuckleRoo]

But in terms of retro homebrew, the entire idea is limiting yourself to a certain hardware definition, so some kind of well defined constraint makes sense. It's a commonly discussed subject, and at the end of the day, people are allowed to make whatever they think is fun to make. But I'd expect them to at least be up front about their product.

Yeah, a lot of homebrew retro NES games I see try to use pretty stock/basic mappers and just push the limits of those. Lots of good stuff like Micro Mages has come out from the homebrew scene.

According to what I've read, the Paprium devs are saying the chip is literally just for adding additional sound channels and isn't doing a whole lot else? Of course, until people examine the game hardware in more detail I guess we won't know how true that is or not.

It does certainly seem against the spirit of homebrew if you shove something like a Raspberry Pi in a cartridge and literally all the processing is handled on the game cartridge itself; it's not really an NES game but rather a game that could be adapted and played on any console, where the console is just a glorified input device...

[Sumez]

Star Fox. *Drops mic.*

I guess Star Fox isn't a homebrew SNES game? You really got me there.

[orange808]

But in terms of retro homebrew, the entire idea is limiting yourself to a certain hardware definition, so some kind of well defined constraint makes sense. It's a commonly discussed subject, and at the end of the day, people are allowed to make whatever they think is fun to make. But I'd expect them to at least be up front about their product.

Yeah, a lot of homebrew retro NES games I see try to use pretty stock/basic mappers and just push the limits of those. Lots of good stuff like Micro Mages has come out from the homebrew scene.

According to what I've read, the Paprium devs are saying the chip is literally just for adding additional sound channels and isn't doing a whole lot else? Of course, until people examine the game hardware in more detail I guess we won't know how true that is or not.

It does certainly seem against the spirit of homebrew if you shove something like a Raspberry Pi in a cartridge and literally all the processing is handled on the game cartridge itself; it's not really an NES game but rather a game that could be adapted and played on any console, where the console is just a glorified input device...

There is no "spirit" of homebrew. It's whatever the dev wants to do.

There's very little difference between using the SA-1 and using a modern processor.

I guess we'll have to agree to disagree. I'm with David Crane. If you can cram it into a cart, "it's fair game".

Frankly, MMC3 adds much more to the game experience and "cheats" a mile beyond using ARM to streamline development. Without it, free scrolling becomes a ridiculous challenge. The NES can't really run SMB3. Use any tricks you want, it can't do it.

[orange808]

Star Fox. *Drops mic.*

I guess Star Fox isn't a homebrew SNES game? You really got me there.

If the devs in the console's heyday could do it, I fail to see why devs in 2021 have to live by your special little rules.

[BareKnuckleRoo]

I too, as an alien being with no perception of the linearity of time, fail to see the difference between limiting one's homebrew development to the official hardware available from the console's era and developing for whatever ultramodern hardware I feel like if I can just cram it in a cartridge. Hardware from the 1990s and 2020s are so obviously indistinguishable.

Frankly, MMC3 adds much more to the game experience and "cheats" a mile beyond using ARM to streamline development. Without it, free scrolling becomes a ridiculous challenge. The NES can't really run SMB3. Use any tricks you want, it can't do it.

It depends on your definition I guess, because lots of games have helpful chips inside their cartridges - almost every NES game has at least mapper functionality, and one of the most common ones also has a scanline counter which added more "features" you wouldn't be able to do on a stock NES. But it's so common that it's almost expected that NES games have that ability.

Sumez addressing orange's points before he even makes them. Ultimate big brain move.

[Sumez]

I don't think what orange808 think I'm saying has much to do with what I'm actually saying though

[orange808]

Yes. People do expect scrolling in their games--and the kids instantly complain when they can't backtrack in SMB1. For myself, I have some knowledge of the hardware and I can't dismiss the MMC chips as trivial.

Users don't know or care about the processor or memory space of the game logic, either. So, I don't see the point. What is the point? Users also expect the game to have logic. What exacly do they know or care about running the game logic?

[Sumez]

Frankly, MMC3 adds much more to the game experience and "cheats" a mile beyond using ARM to streamline development. Without it, free scrolling becomes a ridiculous challenge. The NES can't really run SMB3. Use any tricks you want, it can't do it.

MMC3 doesn't have an ARM CPU, it's a much simpler chip than that.
It's literally just memory mapping and a scanline counter.

Free scrolling on NES is always a ridiculous challenge unless you're using a mapper that allows four screen nametable memory, which MMC3 doesn't. In fact, very few NES cartridges had that at the time, like literally only a handful, and SMB3 certainly didn't. Nearly all the NES games that allow free scrolling in all directions had to overcome that with skillful programming.

SMB3 is a bad example too, as it never scrolls more than two nametables vertically (exactly the amount of memory the console comes with), so it only ever needs to load data horizontally, which removes all of the challenges associated with free scrolling on the NES.

[BareKnuckleRoo]

I don't think what orange808 think I'm saying has much to do with what I'm actually saying though

It was more about the fact that using a mapper in a cartridge was the expectation of the era and it was far less complex than the coprocessor hardware you can stuff in a cartridge nowadays. Mappers were the norm on official Nintendo hardware when it was released and were hardly "cheating" when their use was part of the expectation.

If you cram something as complex as an all-in-one miniaturized computer PCB in a cart which handles everything, and the console is basically just there as a box you plug the controls and a TV into, it'd qualify as a cute hardware project. Neat perhaps, but not something that would ever be viewed as a homebrew game that is designed within the limitations of what could've realistically been made and played in the era the console was released.

68K assembly isn't exactly rocket science, it's one of the friendliest assembly languages to work with, and it shouldn't pe awfully hard to do it legit. And if that fails, you can actually do C compilation for it with very little damaging overhead.

Isn't that what Lizard did? I seem to recall it was actually written in C or C++ and then a conversion program is used to convert it to NES assembler language. Perfect example of a game that runs well if that's the case.

[orange808]

Frankly, MMC3 adds much more to the game experience and "cheats" a mile beyond using ARM to streamline development. Without it, free scrolling becomes a ridiculous challenge. The NES can't really run SMB3. Use any tricks you want, it can't do it.

MMC3 doesn't have an ARM CPU, it's a much simpler chip than that.
It's literally just memory mapping and a scanline counter.

But, it povides significantly more on screen game benefits than the ability to use 32 bit floats and C++. Users can't tell where logic runs, but they'll notice if I take away the benefits of MMC3.

You can't get paid to write 6502 assembler in 2021. I admit my experience with 6502 was the Apple 2--and I dabble with the 2600 for fun thess days. Regardless, I don't and won't write 6502 on my resume.

A living platform caters to developers and development--not some silly ivory tower arbitrary idea of "real programmers".

edit: 32 bit ints. Floats are going to be too slow on affordable ARM.

[orange808]

...it'd qualify as a cute hardware project. Neat perhaps, but not something that would ever be viewed as a homebrew game that is designed within the limitations of what could've realistically been made and played in the era the console was released.

I don't care.

It's 2021. Now, be careful if it rains. You could drown.

[Sumez]

If you cram something as complex as an all-in-one miniaturized computer PCB in a cart which handles everything, and the console is basically just there as a box you plug the controls and a TV into, it'd qualify as a cute hardware project. Neat perhaps, but not something that would ever be viewed as a homebrew game that is designed within the limitations of what could've realistically been made and played in the era the console was released.

It's definitely a cool thing to do, and not exactly trivial either.
It's just something different.

You can't get paid to write 6502 assembler in 2021.

That's not exactly true. I've been offered a few jobs to not only program 6502 stuff, but straight up NES games. If I didn't already have a full time job I might have taken then.

A living platform caters to developers and development--not some silly ivory tower arbitrary idea of "real programmers".

6502 assembly is very simple, and not exactly rocket science. And 68K assembly especially is incredibly easy, have you tried it?
Like I said, you can also easily compile a C program to 68k with very little overhead, so complexity definitely isn't the issue here.

Like I said before, you're definitely assuming I'm implying something here that I just wasn't.
I just think it's laughable if Paprium was advertised as a MegaDrive homebrew project, if the game itself isn't running on the MegaDrive. But hey, maybe it's just an oversized device to produce extra audio channels like mentioned earlier?

[orange808]

@Sumez
Producing sound on the cart is still "cheating". You just have arbitrary qualifications for what is and isn't a Mega Drive game.

Yes. I have spent time with 68k.

Here's the thing, to me: time is valuable. I don't want to spend more time on a project than I have to. If I have the option, I want to use C++ (even better if I can also use scripting) to steamline my workflow. A living platform is friendly to devs and requires current widely marketable skills.

I could probably make more money writing dodgy Ren'py "games" than I could writing assembler.

...
And, of course, keeping some of the game's logic away from the console prevents a new game from instantly becoming a free addition to Smokemonster's flash cart rom catalog.