Gemintronic

I appreciate the time and labor put into the PlusCarts. I've made a small run of 2600 games using 3D printing before. It's never quite a perfected science. You could be into the 12th print and half-way through there's a tray full of plastic spaghetti moving around

It happens in the modified multi sprite kernel used in Flappy Bird. Thought it would be easier to point to the Flappy Bird source than present awful, work-in-progress code. I guess I was glomming on too many fever dreamed concepts. In a perfect world I'd wish that multi colored playfields be integrated into the multi sprite kernel. Also, the glitchy effects when virtual sprites pass vertically through said playfield. It is not a bug in bB. Just an unintended effect in the modded multi sprite kernel Flappy Bird uses. playfieldbleedproj.zip

Good news is that I have yet another reason to make a new 2600 game incorporating the PlusCart.. ..bad news is my methodology of choice is: "Dark Agile" so your royalties may take years with the productivity it delivers

Holy HMOVE bars Batman! Thank you! I'll be sure to put this to good use!! Email sent

Here is an example of playfield background bleeding. Same thing happens in the Flappy Bird clone here: https://atariage.com/forums/topic/222161-flappy-my-1st-released-game/ I'm using the modified kernel files from that Flappy Bird post. In my example just move the virtual sprite around to see how it effects the background. playfieldbleed.bin

I think the Jaguar BASIC used to use BCX to take BASIC and turn it into C. http://bcx-basic.sourceforge.net/ I could swear some people are working with CDFJ and C. Maybe something could be jury rigged from that combination.. https://atariage.com/forums/topic/297759-part-1-cdfj-overview/

Could probably make life easier for you next time you inevitably need to reinstall Windows. Use Double Driver to back up the drivers you installed. http://www.boozet.org/dd.htm Use NTLite to slipstream those drivers you backed up. https://www.ntlite.com Custom "VCS" Windows 10 install disc, baby!

The dream is to keep things as local as possible. Including figuring out how to send and receive level data. I'm stubborn and slow. So, it should take awhile.

My PlusCart arrived a few days ago. Thank you, Al_Nafuur! Now I have to figure out how to set up that Cloud thing and hunt down some example code. Er, and set up my new wireless router. Procrastination leads to layers of things to-do before you can do the thing you want to do 😛

Bought VS Super Mario bros and Solomon's Key. The arcade versions weren't something I played as a kid. The price was good enough. Capcom, on the other hand.. I *just* want to play Commando but I must buy a whole "pack" of games for $15 bucks. No thank you!

Not a proper answer. But, maybe you can contact the guy who makes Seagull 78 adapters. If anyone would know the answer to this that's be the guy. https://edladdin.com/contactus.sc

Maybe an actively maintained Jaguar FPGA core. I'd buy an all new parts Jag.

Perhaps something like SARA RAM where part of the variable means something. Like: var37b12 would indicate which variable (var 37) in which RAM bank (bank 12) should be read or written to. Have the 6502 kernel and ARM code do the heavy lifting of retrieving said value from the ARM resources. I guess an alternative to wait state flags would be to have a function for reading/writing ARM RAM. Said function would return 255 if still waiting. In other words, I'd trade the complexity of waiting for extra variable reads/writes over dealing with low level stuff like push pop foo lang dang whatchahooty.

Not a full ROM pack but I'd really like people playing and critiquing Upp Plus Plus and the rest of my games on Itch. Wouldn't mind if people updated their Homebrew packs to include said games https://theloon.itch.io/

Things like expanded memory management and extended memory management existed in the 286/386 days. Perhaps with a little more code running on the ARM side something can be done to mitigate the complexity for BASIC coders. Maybe something that allows you to request to store ARM variables and retrieve ARM variables. With a special flag raised when said reads or writes have executed. So, it doesn't have to complete right away. I wonder if a routine that pretends to be an internal SaveKey could be made. That's another half coherent idea.

I may have been thinking too VisualbB centric. That IDE has a field for an alternative batch file to be used during the compile process. It's the only way to successfully use VisualbB under Linux/WINE. Anyway, inject your preprocessor into there. My bB laundry list revolves around the plain, old multi sprite kernel. None are actually requests. Just selfish dreaming Multi Sprite Kernel * Seamless/integrated support for virtual sprites in the built in collision function * Seamless/integrated support for playfield collision in built in collision function * Ability to assign sprite data to more than one sprite. * It seems like off screen sprites still effect flickering on on-screen sprites at times. I wonder if designating Y location 255 could tell the graphic kernel to stop processing a sprite and optimize itself accordingly. * Find the CPU time for variable height ball/missiles. I'd gladly sacrifice playfield and sprite resolution for this. * Slipstream playfield background/foreground color support into the standard kernel. * Prevent visual horizontal rebound of sprites when they cross the screen boundaries. I.E. make them seamlessly transition from the screen and loop to the farthest relative position at the other edge. * Special title screen mode with asymmetrical playfield and disabled sprites. Maybe triggered by pfheight=0 * Integrated nybble variable support. Multi sprite games are thirsty for variables! 'Specially in a QuadTari game. * Fix the color bleeding when sprites move vertically through a multi color background. I know this is currently only a feature in an unofficial extension. * Managed sprite mode where player0 is swapped with whatever other sprite is going to cause flicker. So, at least one pair of sprites will not flicker. More RAM and CPU time but less flickery fickering bB games

Could a lateral solution work? Some combination of an assembly include file with new routines and a code pre-processor that converts certain new commands into inline assembly? Yeah, this is a badly explained idea that I hardly understand myself Just trying to think of solutions that don't require extra attention/effort on batari or RevEng.

Priority number one is to get the maximum FPS in screenshots. Virtual Jaguar wasn't good enough so this was my last option! At the very least this taught me how to make a ROM instead of ABS. Also, more incentive set up my actual Jaguar again.

That's because I complained before doing the logical thing and ask for help Sent you the offending Genesis homebrew. Thanks again!

Fired them all up on a plasma TV as well as Stella. Glacier Belle was the most legible for me. The upper case N grew on me.

Yeah. I hoped to leave this here so that when the core improves it would serve as a reminder. Well, poop I wont be offended if this topic disappears.

So, I figured out how to test JagStudio compiled games on the MiSTer FPGA. It has a pretty much abandoned, incomplete core.. but, that may change. First, this YouTube video has a link to be compiled core: https://www.youtube.com/watch?v=OCKsYtjAySU Plop that Jaguar .rbf file into your \\mister\fat\_Console directory. Put your JagStudio compiled ROM files into the \\mister\fat\games\Jaguar directory. I found that the MiSTer core doesn't quite understand .abs files so make a ROM file instead: C:\Dev\jagstudio>build print ROM It's not a great solution. But, it is yet another option!

I think this topic was a product of its time. What I remember was a glut of people asking for free development services without any clear specifications. Also, declaring that game development was worth nothing because: easy. I tried to engage them with gentle push back: show me your game design. Give me gameplay rules. Give me mock up screenshots. That usually caused them to stop responding. A few years go by and now I just see novices willing to at least consider doing it themselves with community support. Elitism and newbie entitlement both seem to be at a low point. I think hashing it out here helped. Also, the general respect AtariAge members have for each other. UPDATE: I just realized I may come off as contradicting what batari just said. Nope. Nope nope. Just adding my own experiences.

Didn't see an option like that. But, I'll check again. Thank you! Problem is: all the people who bought my genesis homebrew who just want to stick in the game and go. They'll just assume my work is awful. I mean, it IS but I'd rather they put in the time to find out themselves

The Mega SG runs my sega genesis homebrew like your typical genesis clone: with super sped up music. This doesn't happen on original hardware or hardware clones like the JVC X'Eye. The MiSTer just updated their core so my games play like original hardware. So, for now: MiSTer 1 Mega SG 0 The neat thing is both systems are FPGA so it's just a matter of who gets updates and enhancements more often.