Gemintronic

I have to commit to someone else making carts and boxes for a whole run of games. The time it takes to recoup enough for another run can be awhile. During interim's like that I've gotten messages demanding free copies. Also, finding pirate boxes for my games on super special forums. Not fun.

You go out of your way to protect enthusiasts from insane unauthorized reproductions listed on feeBay too. Thank you!

If you (the original poster) care enough to collect then repros don't make any sense. Paying the current market value is part of collecting. Or, going to flea markets and/or hunting online for the best price. I'm also wary that unauthorized repros being an "OK" option makes things like homebrew repros "OK" because developers can't make unlimited runs.

Just an update from the developer of Knabber Rob. Knabber Rob is my idea of "What if the Bat had to put back the treasures he stole?". How would it feel to control said Bat? The game has two hand designed 256 screen maps with a third semi randomized map. 8 treasures must be found and placed in their specific chest. Easy mode gives you an echolocation clue to each chest. Neo Games and I have been polishing Knabber Rob further in an attempt to get this game launched. I've incorporated some of the feedback that was gathered between finding new publishers. Some changes with release candidate 3: * New Knabber Rob and Dragon graphics * Completely new world 1 map * All new versions of screens to traverse * Clock timer (6:00:00) changed to hourglass (⏳60) counter. * After 60+ hourglass ticks you *may* get additional time. Chances for additional time eventually go to zero. * Had to change horizontal scrolling a bit due to technical issues

The method I use is to have a counter variable incrementing while the title screen is going. When the user exits the title screen I use that counter to seed the random number generator (i.e. "rand = counter") The player is the best source for randomness as you can't count on RAM being dirty on initialization (to use it for seeding) with every emulator.

I think there was a small amount of time where it was a thing. I wish the trend of all everything cards kept going. I remember a PCI card that was video, sound, modem and ethernet all in one was demoed. Everyone was still okay with a full size case with full size expansion.

Explains a lot about my personality 😛 Though, Uncle Grandpa says I did alright!

Last time I heard of someone performing violence against their property was in elementary school. Someones husband got frustrated with Platoon and threw his NES down the basement. Wasn't good for him, his family or the hardware, I'd wager.

Sometimes you can let the players position determine monster behavior. In this case the AI uses the players (player1 sprite) coordinates to decide some of the dragons (player0) movements. Usually people just use the players coordinates to "heat seek" towards the player. But, you can do more than that. Not really a code example. I glossed over _west, _east, _north and _south being constants. Also didn't explain p0ref being a bitwise define of a variable. Just included the code from one of my games to demonstrate intent movegdragon if direction = _west then player0x = player0x + 1 : p0ref = 0 if direction = _east then player0x = player0x - 1 : p0ref = 1 if direction = _north then player0y = player0y + 1 if direction = _south then player0y = player0y - 1 goto main_begin moveydragon if player1y > player0y then player0y = player0y + 1 if player1y < player0y then player0y = player0y - 1 if direction = _west then player0x = player0x + 1 : p0ref = 0 if direction = _east then player0x = player0x - 1 : p0ref = 1 if direction = _north then player0y = player0y + 1 if direction = _south then player0y = player0y - 1 goto main_begin moverdragon if player1x > player0x then player0x = player0x + 1 : p0ref = 0 if player1x < player0x then player0x = player0x - 1 : p0ref = 1 if player1y > player0y then player0y = player0y + 1 if player1y < player0y then player0y = player0y - 1 if direction = _west then player0x = player0x + 1 : p0ref = 0 if direction = _east then player0x = player0x - 1 : p0ref = 1 if direction = _north then player0y = player0y + 1 if direction = _south then player0y = player0y - 1 goto main_begin

I really want to use pfpixel for procedurally drawn screens. Alas, what I've found is that using several pfpixel commands does indeed exacerbate CPU cycle problems. Also, it seems to use up more ROM space using pfpixel commands than playfield screen sections. Big bummer there 😕 My experiences could very well be my poor coding style in combination with using pfpixel in an unintended way I suspect this is something we'll have to make a custom community version of pfpixel to get closer to some of our needs. Kind of like what we did for the multi sprite kernel pfread.

SeaGtGruff came up with a library to move playfield pixels around. Download is in this topic:

The fellow that I was collaborating with decided to go with an Android based portable so the AFP specific build wasn't needed anyway. I tried this combination as a "best practices" for AFP compatibility: * Manually write zeros to all available RAM * No high res title screen (possible unsupported HMOVES) * Use the AFP safe score kernel for batariBASIC projects. * Fill each bank to the brim with data. Putting in dummy static arrays if needed (hoping the cart type detection is appeased). Trouble is, even with doing that I feel the chance for working is potluck.

What's a good 64 bit IDE to use with this? Also, thank you!

I forgot about the PocketGo. That's a wonderful option! Thank you for reminding me. Was tempted to explore Stella ports for the PSP and DS. But, that would be more hassle then just buying a portable that intentionally facilitates homebrew.

I appreciate the insight! I might try to use the modified standard kernel and write zeros to available RAM at startup and try again. I accidentally posted in the general development section but also [ now ] realize any fixes are probably by assembly coders. Should expect to insert some inline assembly for said fixes.

I've got an upcoming title that needs to run on an Atari Flashback Portable at an expo. No power at the tables. Is there a complete (as can be) list of fixes to get things to run on the AFP? Seen a score fix: https://atariage.com/forums/topic/281369-atari-flashback-portable-score-fix-for-bb/ ..and, I vaguely remember code to initialize memory? If anyone else has a clue about that please chime in.

It depends on which kernel you're using but all of them I've seen have this behavior. The only solution I've come up with is to manually figure out which x position each sprite needs to stop at before looping. Typically using some code to display the x position as a decimal number in the score.

I usually include the 6lives_statusbar.asm https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#lifecounterstatusbar Gives you a long status bar and a sprite life counter. Good stuff!

In another thread someone was trying to use data tables for sound engine use. I suggested using seperate variables for each sound that would act as both duration and the sound effect itself. Nukey Shay suggested using a variable for bitwise flags and another variable for duration. My addled brain came up with a scheme that has a big problem: Say, an enemy needs a torpedo sound. Simple! Raise the torpedo sound flag and set the duration: def torpedosound=soundlfag{0} def lasersound=soundlfag{0} soundflag{0} = 1 duration = 25 But, now the player fires and needs his laser sound played. So, we set the laser sound flag: soundflag{1} = 1 duration = 35 The torpedo flag hasn't finished yet so the duration get overwritten with the duration of the laser! I can also imagine the game needing the opposite where a laser sound is playing but needds the torpedo sound to play (thus overriding the torpedo sound). I never had to worry about this with my single variable for a specific sound method. Each sound was always run if it was more than 0. Since the variable was also the duration each sound couldn't mess with the others duration or priority. How does one use just one variable for sound flags and a single duration variable given the two issues presented (priority and duration being overridden)?

I usually use a duration variable for each sound effect. So, to activate a laser blast sound I set its variable to something non-zero like 15. Each cycle of the main program loop I check for the laser blast sound variable to be more than zero. If it is I set the sound registers appropriately and then decrement the laser blast duration variable. The big drawback is, of course, each sound effect takes up an entire variable.

For the kernels that support pfscroll you could make a routine that pfscroll's up or down determined by a counter variable that increments at the top of the main program loop. For more fine grained shaking you could play around with playfieldpos With help from bogax I created a 4 way scrolling demo that uses playfieldpos. https://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/

I've not heard of a homebrew ROM that doesn't work if given the proper physical cart and board. Some games might better on either a real TV or LCD panel. For instance: Some games flicker the left 8 pixels of a sprite then the right 8 pixels of that sprite. So, you see only half the sprite at any one time. Depending on using a CRT TV or LCD monitor it may look hard to see.

Looks like it's scripted. But, I like the idea of BASIC within BASIC

I'd talk to a lawyer before plunking money down to try to rent someone's dump of their games. Right now it sounds like you're going by what you think is allowed and what we are pretty sure wont work. Alternatively, you could avoid the issue altogether by getting permission from homebrew authors to stream their games. You can test the waters with offering retro titles without incurring the wrath of Nuntendo, Atari, etc.. I'm sure many game makers would be happy to see their game shared for a little slice of the ad revenue or subscription fee.

I think the conundrum here is that, in keeping with the no illegal ROMs criteria, collectors would have to sell you their physical collection. In the US you can still make personal backups. So, you get their collection and then you personally dump the ROMs. Am I looking at this wrong?