Gemintronic

I got an early version of the RatRace (want 4 way scrolling topic) engine a little bit cleaner but it still goes over cycle. I'm going to try reducing the playfield resolution and see if that cuts down some cycles. Maybe we'll end up with a presentable example some time down the road UPDATE: Eternal thanks to bogax for the heavy lifting in scrolling routines!

I should also clarify that, although I am appreciative of people who buy new games, I don't expect them to pay an arm+leg. My boxed games are published my others who are better at that sort of thing. When I self publish it's either cart only or inexpensive packaging. Plus, most of my games have early versions in ROM form. Kinda try before you buy. I hope to continue that with my Inty games.

I agree in general but does this one here count? I thought it was found to be using someone elses code. Maybe I'm posting in the wrong thread?

Does this count as a homebrew? I mean, when something is widely regarded as an unauthorized mish mash of someone elses work.. I'm not sure that constitutes a legitimate product. I appreciate your enthusiasm for homebrew. I strongly suspect some of my games were bought to support homebrew and collect new games. At times that little bit extra helped me make a second run. Or, purchase equipment like a 3D printer which let me support friends in their homebrew products. Your openness has exponential benefits.

I don't remember making a comment about the Legends product. But, I could just be having a brain fart. Nothing against it but my thing is system clones with cart/SD card support.

Obviously we are not the target audience for that comment Bill. I love AtGames Genesis clones

I was thinking of making a Megamania inspired game. This topic has become so popular I might change that to "Copy Pasta Masta"!

I'll see if I can walk through your instructions to get a better idea of what a full IntyBASIC environment would look like.

You cannot swap color statements made for player0 or player1. Altering the start and end of a sprite does not let you mix and match arbitrarily. Basically, you can make one very long sprite and move the pointers up and down to present a vertical slice. You CAN mix and match sprite data and color data for a specific player. So, you could have player0 sprite data with a purple bat and a yellow key on one sprite data block. You could use a different player0 color statement to have a purple bat and a black key.

I think the assembly coders would be nonplussed. If they do have hobby time for a contest then they could easily create a better looking graphic kernel (compared to BASIC or even C entries) However, you'd gain all those batari BASIC game makers. Some will be seasoned and some will be excited newbies. Let the votes sort the results out. Again, it depends on what your end goal is. Promote assembly programming or promote 2600 game creation in general. UPDATE: How about allowing alternative languages *IF* they have assembly routines included or inline. Although the routines would not have to be entirely by the game maker at least one element needs to be hand altered by the contestant. Contestant should describe their hand written assembly additions in the entry.

I've got a really old game called "Nitebear on Sleepystreet" that Neotokeo2001 got signed by Freddy Krueger Robert Englund http://atariage.com/forums/topic/169496-nitebear-on-sleepystreet/

Well, it's a anti hacking/watermarking technique. Not necessarily something obvious (or not obvious) to the user. Just something that can be detected once some genius decides to take a pirated ROM and make reproductions.

My cousin and I played a LOT of Treasure of Tarmin. Eventually this would happen. Have not tried laptop stands myself.

My jr broke. Light sixer still working fine. 7800 has nearly daily use (in 2600 mode). I dig the look of my Gemini and Jr but.. just afraid to wear them out now.

I can't answer for AtariAge the second part of your question about game demo videos for YouTube. I can say how I do it: for games that I have permission for I have a digital copy and play it back via Stella or a flash cart on real hardware. Either I whip out a camera or video capture device. Honestly, taking an emulator like Stella and OBS for the recording is a much cleaner option. https://obsproject.com/

Allowing other languages would make it more open and widen your contestant pool. 2k games can certainly be done in batari BASIC. But, that would dilute your intention to promote assembly.

Again, you try publishing 200 carts in boxes on a low income budget. I'd put effort into finding ROMs that the developer intended to be free ROMs. I gave you links for those exact type of ROMs. There's no justification for complaining about commercial games not being free for you. I don't mean that in an angry way. It just doesn't make sense. UPDATE: If you ever need more intentionally freeware ROMs I can provide more links.

Looking forward to hearing about the tools and techniques you use. Particularly the IDE. Been looking to expand into the newer Atari consoles like the 7800 and Jaguar.

Perhaps since we can't prevent screen roll and artifacts during some bank switches we could mitigate it. Say, have a section to clear the screen and color the sprites and playfield black before making the jump. Maybe doing an extra drawscreen immediately before the bank switch. I realize it's bad form to ask the inquirer things he's asking about, but.. Have you experimented with switching between standard kernel variations. Say, one bank "player1colors playercolors pfcolors" and another "pfcolors no_blank_lines"? Hopefully our findings will inspire others to take the plunge

Haven't checked the status/availability in awhile. I respect him too much to bug him like an excited teenager. Plus, this year has been rough

Seems to work so far. Have not stressed it for going overcycle and real hardware yet. I got the impression the developer of batari BASIC was having trouble finding the cycles for further features on the multi sprite kernel. If you think you can do better I'd test the heck out of a new multi sprite kernel

I'm biding my time until I can secure 256k ROM boards. You're pretty much a trailblazer here. I'd love to here if you've had success mixing and matching kernel options. I know multi sprite and standard didn't mix well (blank screen).

The 2600 has only a few resources that can be drawn (besides then playfield) across the screen: 2 sprites, 2 missiles and the ball. In batari BASIC game makers experience these objects as 2 8 pixel wide sprites and three rectangular solid boxes. But, at a hardware level it's more like these are five different crayons that can be dragged across the screen. Ed Fries chose to draw the player layer by layer with one crayon then switched to another part way through the helmet area with a different crayon. So, he wasn't breaking any rules getting the player sprite to be two colors on the same line.

Like I said: you have to take into account we're all enthusiasts on a budget. Try paying rent, doctors bills and have a family AND pay for a run of 2 dozen carts up front. Demand can be fickle and you might not sell through your next batch either.

I'm still in the 2600 camp but it should still apply .. I usually increment a counter variable at the beginning of the main loop. Using bitwse operations I can decided when to move: Basically, the code below moves the player every other frame. main counter = counter + 1 if counter{0} then player0x = player0x + 1