Donkey Kong 3?

[Donkey Kong 3?]

Non Trademark infringing titles could be:

 

Monkey Bee Monkey Do!

Hives 5

Honey Monkey

Garden Gorilla

Arboretum Ape

[First row gets last row color]

If you throw in a 12th line on the pfcolors definition, it should change that first row to that color. It has to do with the fact that there are 96 rows for the playfield, even though bB only uses 88. At least I think that is how it goes. Try using no_blank_lines and see if that changes it as well. If you look at the bug thread, you can see us talking about it. It may apply to that as well. Hope this helps.

 

Cliff

 

Hey! Thanks for the help! PAC-MAN-RED too as that topic was educational as well.

 

The workaround seems to be adding an extra line to the top of the playfield data and adding a corresponding pfheights. Adding a pfcolors line doesn't seem to efffect it.

 

I still consider this color wrap-around issue a bug (albeit with workarounds). Just have to watch out for it in the future

[Places to Submit Homebrew ROMs]

What's wrong with announcing it on AA if its Atari related?

 

 

First choice is always first and best and wonderful. Rock on AtariAge!!!!!!

 

Can you recommend a good second or third choice GroovyBee? Or, are you saying posting your creation on only one website is good enough?

 

If you post it in the Homebrew Discussion section, it will usually pop up on PDRoms's news feed in the next couple days.

 

That's a good suggestion and makes sense. However, I'm less enthused about PDRoms now that I know registration is closed. At AtariAge I get input and can take part in the process as a member. Not so much with PDROMs apparently.

[Digital Distribution of Homebrew Games]

Whatever happened to shareware? You tried the full version. You liked. You bought. Pirates and Ninjas continue fighting as they always do. That's background noise.

[First row gets last row color]

For some reason the first row get the last rows colors.

 

 

 set smartbranching on
set romsize 4k
set kernel_options pfheights pfcolors

COLUBK = $00
scorecolor = $0E

pfheights:
4
26
16
26
4
2
2
2
2
2
2 
end

pfcolors:
$33
$33
$33
$33
$33
$33
$8E
$8E
$8E
$8E
$8E
end

playfield:
XXXXXXXXXXXXX....XXXXXXXXXXXXXXX
X..............................X
................................
X..............................X
XXXXXXXXXXXXX....XXXXXXXXXXXXXXX
................................
XX..XXX.XXX..XX.XXX.XXX.XX..XXX.
X.X.X.X..X..X....X..X.X.X.X.X...
XXX.X.X..X...X...X..X.X.X.X.XX..
X...X.X..X....X..X..X.X.X.X.X...
X...XXX.XXX.XX..XXX.XXX.X.X.XXX.
end

main
drawscreen
goto main

[ATARI 2600 is back !]

The last is that you can't write to the images or save snapshots.

 

That's a big deal to me. Sounds like games that save your game like Ultima may not work. Also, I'm spoiled by flash carts that let you just put the ROM on the media and play. Editing XML files is not my idea of fun.

 

I give these guys props for using C64Forever. Hopefully this means you can program in BASIC using the real licensed C64 ROM, right?

[Donkey Kong 3?]

Donkey Kong could be just part of the playfield. You'd store separate playfields for every DK movement up toward the bee hive.

 

The score could be made into 6 flower sprites. You could even (I guess?) use SeaGtGruffs gosub + inline assembly technique to switch between score kernels to go from flowers to score numbers. Or, you could use the examples where you extend the score kernel to include more characters so you could retain the numbers AND have the flower sprites. Yet another idea is to use the score bars as flowers but that would look less authentic.

 

The score bars could be used to represent to time left. Whatever the bullet and R= are on the top left could be represented by the other score bar.

 

Mario could be the player0 sprite and the bees player1 through 5. When the hives drop just make the bees disappear and use their objects as the beehives. Change the playfield to Donkey Kong all the way up with the middle bee hive on his head.

[ATARI 2600 is back !]

I'm usually a sucker for this sort of thing (gadgets) but $219 is a bit pricey for me for what it does now. (just for C64 and Amiga.) Throw in 2600/5200/7800, MSX, and Spectrum and you've got my money.

 

The only cores available on their website are for C64.

http://mcc-home.com/3.html

 

We are working on the AMIGA and ATARI 2600 support right now.

Since the OP turns out to be from the company making these I wonder if he could tell us when Amiga and 2600 support will be available? At least a guess? Does Dirk Dudenbostel do all the FPGA programming?

[Example Program: Shoot Missile in 8 Directions]

I'm interested in the advanced joystick reading code. Reading SWCHA and on goto/gosub seems to be the way to go. Comments are nice. The asterix's makes them stand out and are much more readable.

My emulator doesn't seem to want to continue going diagonal. I get the inital keypress in and then it veers straight north or south. My guess is that Keyboards Are Evil.

[Developers view old used games as similar to piracy]

Well, the first peeved software house the article mentions is THQ. Makers of 10 out of 10 material such as "Bratz: Super Babyz"

 

I feel sad for the guy who had to pay full price for that.

 

Joking aside the heart of a game company is the actual artists and code monkeys. Creative Director sounds like an uncreative management job to me. Out of the loop and into their own world.

 

UPDATE: Looks like they noticed their customers were less than pleased..

http://www.gonintendo.com/viewstory.php?id=134143

[Animating a sprite]

main
rem Set the background color
 COLUBK=$02
rem Set the player color.  Note this must be done after EVERY drawscreen.  
 COLUP1=$28

rem Increment or decrement our counter by 1 using the joystick
rem Note we didn't have to dim this variable as we used its
rem original name y
if joy0right then y = y + 1
if joy0left then y = y - 1

rem If user goes past the max animation timer amount then reset counter.
rem note that y becomes 255 after subtracting from 0 so only one IF statement
rem is needed to check for over and under limits.
if y>30 then y=0 

rem When the counter reaches 10 then
rem change to this sprite image.
rem Note that by waiting 10 loops it adds an
rem appropriate duration for each animation step.
 if y=10 then player1: 
       011100
       011000
       011000
       100000
       011000
       %01011111
       %01100100
       010000
       011000
       111100
       011000
end
rem When the counter reaches 20 then
rem change to this sprite image.
if y=20 then player1:
       %01000011
       %01100010
       110110
       011100
       101000
       111100
       100100
       010000
       011000
       111100
       011000
end
rem When the counter reaches 30 then
rem change to this sprite image.
if y=30 then player1:
       011100
       011000
       011000
       100000
       %01011010
       %01111100
       100100
       010000
       011000
       111100
       011000
end

rem Reset counter so animation loop can start over
if y>30 then y=0 

rem Center player position on screen
player1x=50:player1y=50

rem Refresh the screen so end user can see animation
drawscreen

rem Got up.  Went to work.  Going home to start over. 
goto main

[ATARI 2600 is back !]

Arcade Retro Gaming decided to support the ATARI 2600 on their Multiple Classic Computer.

 

I must apologize for thinking this was a spam topic. I recently received indisputable proof that MC does 2600.

 

Sign me up for 2 and 1 copy of NES ROM Maker.

[ATARI 2600 is back !]

The creator of this product told me at CGE that you could add new games using a MicroSD card. If that's the case I'm very intrigued by this project.

 

Still, I'm a novice when it comes to hardware and software emulation. Someone tell me why this product is better than something like a modded Xbox?

 

http://www.youtube.com/watch?v=3QFvLB7PZwE

 

53 emulators on one Xbox. All with Icon based browsing, save states, cheats, screen shots for browsing games, etc.

 

The XBox can be bought, softmodded and emulators installed NOW. MMC can only do C64 NOW unless the OP posts a link that states otherwise. Oh, and used XBox's are dirt cheap too.

 

I really think the MMC people should consider selling this thing for what it is: A new, almost feature complete C64 system for games. I'd consider buying it for that - not promises to support Amiga, 2600, Double Rainbow Zombies, etc..

[ATARI 2600 is back !]

Couldn't find any 2600 info on their site. Even used their search feature. Nothing but promises on Amiga support too.

 

Would love it if Amiga and 2600 support are actually in place. Is their another link that states Atari 2600 is now supported?

 

@Rom Hunter: Apparently it has a Micro SD slot to add games. Note that I believe for now it's just C64 games.

 

Unlike the Minimig which is sold as an Amiga on a FPGA which theoretically can be reprogrammed into other machines the MMC people continue to elude to supporting MSX, Amiga, 2600, etc.. even though actual support isn't there out of the box. I don't like that kind of marketing.

[2600 Treasure of Tarmin Videos and ROM]

Back a few years before I was interested I SWORE I SAW a 2600 ROM for the prototype 2600 version of Treasure of Tarmin. A few years later I swore I saw a Youtube video of the 2600 version. Even thought I saw a link to the Youtube video here at AtariAge.

 

The kidscentre.com thinks they have the ROM (but they don't)

 

Chris Ware from associated content thinks that a ROM is out there:

http://www.associatedcontent.com/article/1476288/classic_atari_advanced_dungeons_and.html?cat=19

 

Did the ROM exist? Did the Men in Black wipe Youtubes memory of all 2600 Tarmin videos? Am I tottaly going coo coo for Cocoa Puffs?

[GBA Clone]

I'm curious to see how it performs in the real world as well. If the battery life is as poor as some of the reviews say you're better off buying a real GBA with flash cart. The Dingoo 320 seemed to have good battery life and acceptable framerates playing GBA..

[Places to Submit Homebrew ROMs]

What's wrong with announcing it on AA if its Atari related?

 

 

First choice is always first and best and wonderful. Rock on AtariAge!!!!!!

 

Can you recommend a good second or third choice GroovyBee? Or, are you saying posting your creation on only one website is good enough?

[Places to Submit Homebrew ROMs]

In my homebrew seeking days I always went to PDRoms.de to find new games. Now that I want to code homebrew games I realise no one can actually join and submit new games to them.

 

What other homebrew ROM sites exist? I mean, ones you'd actually want to submit your creations to?

[4 Way Scrolling Platform Engine]

Maybe you can add some random terrain to the engine Seriously!

 

Some of my code is wacky because of workarounds. Most of it is whacky because I represent all that professional developers hate I wouldn't be surprised if the authors of Microsoft Code Complete have a hit on me!

 

The whole collisions get registered only after drawscreen thing sucks. Not bB's fault at all but I don't like it one bit. I literally have to move the sprite into the wall and run drawscreen to detect the collision. It looks bad when I then have to redraw back at the non-contact location. Bouncy bouncy flicker flicker. Thankfully, I only have to call the collision routine once. The rest is pfreads.

 

I still think this topic http://www.atariage.com/forums/topic/148427-vertical-scrolling-through-a-playfield-that-wont-fit-the-screen/page__hl__defaultbasbin has the key to multi-screen platforming goodness. Even if I can't figure out how to pfscroll left or right at least that topics examples can go up and down. See Kung-Fu Master CurtisP's Scroll3A.bas for what I mean.

[4 Way Scrolling Platform Engine]

*somehow got double-posted*

[4 Way Scrolling Platform Engine]

Didn't want to hijack jbs30000 platform thread so I'll post this example here.

 

This has:

 

4 way scrolling (up, down, left & right)

Workable collision detection. Not perfect but good enough.

Variable jump.

Basic animation for player sprite.

 

This does not show off level loading. The "level" is one screen big. Someday I'd like to figure out how to use pfplayfieldpos to get taller playfields to work but it's beyond me.

 

Hopefully this example will encourage further platforming advances!

pfplatform.bas

pfplatform.bin

[Strange Atari Fan Rant]

Feels like someone did a babbelfish translation over and over until they got back to English. Maybe it's a code. Too tired to add up the letters or pick out every first letter.

 

Anyway, we seem to be getting more and more attention seekers. Joes Crack and all.

[Passthrough 2600]

There's some addiction to this game. I do think getting reset back to the first line is too harsh. Maybe one or two lines back depending on difficulty..

[New build: Improved if-then]

The problem is "foreground_color" has the "for" keyword so bB is attempting to parse it as for-next loop, which fails.

 

 

For some reason I always suspected my variable and constant names stepping on eachothers toes. Thanks for clarifying!

 

By extension does this mean any program label, variable or constants need to watch out for this gotcha? If so, maybe I need to print out a keyword list and double check my code..

[New build: Improved if-then]

This seemed to fix using def'ed binary values in IF statements but I still wonder why dim'ing COLUPF doesn't compile..

 

As a side dim background_color=COLUBK compiles just fine.

 

Does work now:

 

 dim counter = a
def march = counter{4}
if march then pfscroll down : REFP0 = 8

 

 

 

Never worked:

 rem Can't foreground_color=COLUPF for some reason..

rem Declare constants
const c_aqua = $B8
const c_black = $00

dim background_color=COLUBK
dim foreground_color=COLUPF

rem Init variables

foreground_color = c_aqua
background_color = c_black