ScumSoft

I see a drawscreen, might have added it after you posted.

That's why there is always batariBasic.

Those new to programming should follow these steps for completing a game: 1) Write down a complete outline of what you want your game to do [example] * Donkey kong: * A gorilla stands at the top of the screen tossing barrels down sloped ramps and ladders * The player must jump over barrels and climb ladders in order to rescue the fair maiden penelope * The player can gain the use of a hammer which allows the destruction of barrels, however the player cannot jump while using it * Once the player reaches penelope, Kong will then kidnap her once again progressing the game to the next level * The player will gain score for jumping over the barrels and destroying them with the hammer * The player can lose a life by touching either barrels, kong, or falling from the ramps * A timer will be counting down and will represent the bonus points awarded after reaching penelope * After a few levels have progressed, the player will then rescue penelope and win the game Note that this is just a general outline of what you would like the game to do. This should only represent the goals of the game, and a brief outline of the game mechanics. Nothing to in depth or thorough about it. This will be a reference while your coding the game to ensure what your designing meets the initial goals and ideas set forth. Do not keep changing this as you think of new ideas, only change it if you've come up with something completely different, or if the initial premise has changed. 2)Start SMALL! since you're new to coding don't start on the full fledged project from the get go! Since you need to learn the basics of the language, and about game design in general, I suggest starting by tinkering around with basic functionality. Making a player jump across the screen sounds easy right?! but did you know that loops and slight physics are required for this? Also do you understand how the screen is even prepared to draw your player let alone animating him? You will once you go through a few of these tutorials. They show how a basic kernal is created and looped through. Use those tutorials as a base to ensure your compiler and IDE is setup correctly. If those do not compile and run then you have some issues that need fixed before proceeding. 3) Once you understand the basics of entering your main loop, and then gosub out to desired functions, you can start building a prototyped framework for your game. YOU DO NOT HAVE TO GET EVERYTHING RIGHT THE FIRST TIME! Very important! I've seen many people get burnt out before anything really was done simply because they kept tweaking their code over and over, yet made no real progress at all! Write down everything you want the game to do, down to the smallest detail and keep it on hand, you'll be referring to this allot during your coding. Also be sure to comment plenty while you're writing your code, this will come in handy later. (just trust me on this one) [example] rem set batari kernel options set tv ntsc set romsize 4k set kernel_options playercolors player1colors pfcolors rem Variables, we have 26 of them for general usage rem Setting a variable to something.something uses fixed point math, or in other words floating mathematics for decimal movement rem Set players Y position to decimal dim P0posY = player0y.a dim Gravity = b.c rem set players initial position player0y = 50 player0x = 20 rem Give gravity an initial value Gravity = 1 rem Our main game loop for a simple jumping test MAIN_LOOP gosub get_input gosub do_physics gosub level_data drawscreen goto MAIN_LOOP get_input rem if we press the fire button the player will move up on the screen if joy0fire then P0posY = P0posY - 1.99 if joy0left then player0x = player0x - 1 if joy0right then player0x = player0x + 1 return do_physics rem Apply gravity on players position, also make sure player cannot fall off the screen P0posY = P0posY + Gravity if P0posY >= 81 then P0posY = P0posY - 1 return level_data rem this holds current level and player graphics rem has to be read before drawscreen each loop pfcolors: $08 $08 $08 $08 $08 $08 $08 $08 $08 $08 $C4 end playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end player0color: $1E $1E $1E $1E $1E $1E $1E $1E end player0: %11111111 %10000001 %10011001 %10100101 %10000001 %10100101 %10000001 %11111111 end return This is a basic program with calls to subroutines which perform a simple task. When you hold the fire button your player moves up, and when you let go gravity gets added to your current position causing you to fall until you hit the ground. This isn't how you wan't your game to react, so you have to think now how you will make your player jump movement work like it should. How do you set a value by tapping the fire button and have him launch into the air a certain height, then fall back down. I would suggest thinking this out logically, and then write some test code using this template and see how it works out. If you simply cannot figure it out, then you can get the answers and cheat in this example by RT. Start small like this, use it to test different functions your game will have, and save out the working code! You'll reuse it later, so keep what works on hand. 4) Start migrating your working test code into your main project and start working in all your desired functionality. 5) A few months later you'll have a decent looking title (hopefully) 6) If you have ANY issues, be sure to keep in contact with us here, I'm sure we'll be more than happy to assist where we can. Use our knowledge as a valuable resource and you'll make much faster progression. 7) Don't give up when something stumps you! See suggestion #6, it's easy to get overwhelmed when your new at something, but given some time, things have a way of going click! and making sense. Aside from the afore mentioned, I can't think of anything else to suggest at this hour. Hope to see a working title from you in the near future. There are plenty of code examples here, but you might have to go looking for em'

I suggest you read what I've posted over in the other thread here. It's good info for anyone wanting to get started.

The first example pulls the range as defined in proper order, second example pulls the last digit first since the pointer is at S2 when you pull the value into S0. Right?

Changed from Lunar Cluckerz project to EggVenture. Updated first Post

I wonder what happened to my attachment, well here it is again TRIPLE POST!!! Deadmau52011_06_03_213755.zip

Here I was writing out a long technical post on the inner workings and tricks used when I could have just summarized the entire thing in one word: MAGIC! Yes programmer magic using hardware timing tricks to pull off more than two sprites per scanline, in fact I think the limit achieved so far is 15 per scanline, although this doesn't mean different graphics per sprite. The current limit for different graphics per scanline is 10 I think using just the player graphics and not the missile or ball units. I haven't looked over the Berserk source, so I am not sure what type of tricks they are pulling. Perhaps someone else can explain the intricacies of this game.

I read about the endif statement from RT's reference site, I understood it wrong Thanks for the update

Ok here is my submission, took a bit longer than 2 hours though. I have no idea how to do proper paddle support, I tried to get some code going but it doesn't work. You are free to modify the code if you want to play with paddles [edit]A bit of story: "After a but of a mau5 outbreak in the castle, the mice are being beheaded and tossed over the castle walls. Catch the poor Deadmau5 heads with the cheese and let them RIP" The game will get progressively faster the more heads you catch, miss 5 times and it's game over. Play with the Joystick for now, unless someone can teach me how to make the DPC+ like paddles.

OK! I'm on it, currently coding a Kaboom clone with Deamau5 heads

Here is an example of a few current bugs I've come across while working on my game: Control each with the joysticks * No collisions work in an if...endif statement, stella shows we get stuck in a bmi inf loop * Player0 horizontal screen wrap doesn't work by default, but it works fine for Player1 * If Player1 reaches the score Y offset = 168 then the harmony system crashes, stella just jumps a few frames and recovers. (Sprite height doesn't seem to matter) [edit] forgot to attach the files DPC+debug.bas DPC+debug2011_06_03_165049.zip

Most commonly cpu bit depth is derived by the CPU's largest registers bit count, not the address lines as others mistakenly believe. Therefore since the 6507 has 8-bit registers, it is an 8-bit processor. (tongue in cheek)... and the atari jaguar is really 32-bit since the 6800 is the cpu and the rest are custom chips which are NOT classified as cpus, so it is therefore not a 64-bit platform as advertised but really a 32-bit one. NES is 8-bit Snes is 16-bit Genesis is 16/32-bit Motorola 68000! 32X is 32-bit SH-2 x2 Saturn is 32-bit SH-4 x2 N64 is really only 32-bit and uses the same R3000 cpu as the playstation1. The playstation2 is advertised as 128-bit, but has a 64-bit cpu that can treat 2 registers as one, combining to 128-bit But is really only 64-bit Gamecube is 64-bit PPC Xbox is 32-bit, Custom intel P3 CPU X360 is 64-bit PPC x3 Playstation3 is 64-bit PPC x1 My laptop is then 64-bit as determined by the cpu. It's no wonder people as so confused by how many bits things are.

My code compiled and runs just fine with the updates. The playfield is looking correct now, although there is still a scanline offset present in the score region that affects the left health meter. Tis but a minor issue much obliged kind sir! [edit]The issue crops up when pfscore2 has bit 1 set, then it shows a block that is one scanline taller than those to the left of it.

That solved the bouncing issue thank you. I can remove my workaround now and spare some cycles Now how do I go about removing the stairstep gfx bug? I can just edit the source myself if you'd like to hold off on the update package, just tell me where the issue is being caused and I'll go patch it.

I'm not using those features myself, so toss the current build my way. Much appreciated!

It looks like the DFxFRACINC pointers get overwritten during the kernal setup, so it loses the values we specify for the playfield. So a workaround is to rewrite the DFxFRACINC pointers every frame. No more bouncing.

Ok found a workaround for the bug, you just update the DFxFRACINC pointers every frame and it won't bounce. [edit] Batari fixed this in his latest release.

It's easy, just yell: BATARI!!! Ok, he's coming now While he's here, perhaps I could get the latest batari Basic DPC+ kernal build. :wink: :wink:

I reversed the gravity on that level for a different touch, it may or may not appeal to many though. It's odd, since none of the binaries I've posted worked on my harmony. I've tried many different DFxFRACDATA values for the playfield and different playfield heights, but they all bounced. I'm sure it's most likely some oversight of mine. Thanks for helping me test.

Latest build posted, all game mechanics are in place and playable albeit buggy in some situations. Still doesn't work on the harmony for whatever reason. Anyone have ideas what might be causing this?