jrok
-
Content Count
1,156 -
Joined
-
Last visited
-
Days Won
5
Posts posted by jrok
-
-
I noticed there seems to be some sort of problem with using fixed point math and batari bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions:
Sub44from88 0000 ???? (R ) bs_mask 0000 ???? (R )
...and the following for fixed-point additions:
Add44fto88 0000 ???? (R ) bs_mask 0000 ???? (R )
Does anyone know what these errors mean, and if there is any way around them?
Thanks,
Jarod.
-
Before I put this in a game, please take a look at it and see if you'd actually like to play a game using this random 'maze':demo_maze_2008y_10m_15d_0416t.bin
In this demo, you can bring up a new maze by hitting reset or the fire button. The general maze shape is based on one that atari2600land posted:
http://www.atariage.com/forums/index.php?s...t&p=1590593
Since I'm not good at dreaming up some kind of amazing algorithm that can create a maze using only a few lines of code, I'm forcing the maze into existence by splitting the maze up into three parts (7 random pieces each) and trying to make sure all of the pieces fit. Although parts of the 'maze' will be symmetrical once in a while, it's mostly asymmetrical because I found out that a symmetrical maze of this small size can give you kind of a claustrophobic feeling.
After looking at as many mazes as possible by hitting reset or the fire button, does it look like this is ready? Would you want to play a game in these 'mazes' or do you think I need to adjust something first?
Thanks.
This is cool! It seems just random enough, with each maze being unique but navigatable. One thing that might be cool to add would be to use pfpixel to make an exit appear in a random postipn somewhere along one of the four external walls. Maybe when you pass though it, it could connect you to a new maze... just a thought.
In general, this could be the basis for a really cool pacman-type game. Ms. Pacman used to bother me because I'd be doing much of the same pattern repitition every screen, so even a subtly random element like rearranged portions of the maze could really keep someone on their toes.
-
Are you having any trouble using Superchip RAM? Is it less complicated to use than it looks?You know, I wasn't having trouble until I started to incorporate bankswitching. I had myriad problems trying to use batari's
included bankswitching routine, but then I tried using SeaGtGruff's superchipheader_SC.asm and most of the problems disapeared. The only trouble that remains is that I get compiler errors when I try to use negative fixed-point variables and
bankswitching, but I'm not smart enough to know what's going on there. I shelved it for now to hopefully figure it out at a later date.
About filling up banks, I can do that without blinking. I'm a master of bloated code.
That's the main reason I haven't posted much of my bB source yet. I just know it's just sloppy work, and its probably due to years of grinding out fast and dirty projects with IDEs like Flash, where your code can be a total pig-sty and still compile. Actually, one of the reasons I decided to take up this hobby is to force myself to be a more efficient programmer and hopefully develop better work habits... but so far I'm still a bloody hack.
-
Well, I'm a total newbie but the way I've been approaching Atari design so far is to start out with all the bells and whistles (32kSC bankswitched) see how much memory is actually being used to do the most important things I want the game to do, and then pare back on the code and the number of banks used. So far I've been keeping all my routines in 4 banks and haven't even come close to filling them up yet, so I'm hoping I will end up with a 16K game.
-
I notice when I press down and left, I turn into the red bouncy thing. Is that a feature or a bug?I still think this is more fun than Xenophobe.
Heheh, yup that was a bug. Thanks, man, I think I squashed it now. I also added a few new things, including a Spaceship (for escaping the game, eventually). Check it out.
-
I had to make a atari game for my embedded games class and made this one I call "Ball-Crip" using batari. It's 2 players and the point is to knock the ball into the other person's goal. It's pretty fun and we've played it a lot in the lab here.I've attached the source code to this message in hopes that someone will want to add playfield collision functionality. Right now it doesn't actually calculate collisions with the playfield; it just knows where the outside borders are. It would be nice if we could make different levels with various playfield obstacles to keep the gameplay strategy fresh.
If you just want to look really quick here is a link to it running in JStella:
http://www.mpdairy.com/games/ballcrip.html
For the binary attached here I used batari's scoring but I blanked out all of the digits so they wouldn't show up (I just changed the actual bitmaps in the asm file), so if you recompile the basic code they'll probably show up in your new binary.
Thanks to "SeaGtGruff" for helping me with negating fixed-point numbers.
It's a cool game,. My only thought while playing it was that it handles a little slow.
I suppose for the playfield collision you could statically define them in a data array using pfhline and pfvline to draw them, then select which one to use before play begins.
Another interesting feature might be to add some button functionality. For instance, what if a button press drew a temporary wake of playfield pixels, that could be used to block/angle shots (like the tron cycle's wake, expect disapearing after a few loops?) With the players so small and the handling so slow, it's hard to home-in on the puck, so this might lend an extra element of surprise and stategy to the game. Plus, if you have a mode select before play begins, I suppose you could turn that feature on and off.
-
Is this what you mean by constant?Nope. If it is outputting at 262 scanlines, every frame needs to be 262. The swag he's talking about is although 262 is your baseline, some games output at 264 or something else close. But every frame needs to be the same or you'll get jitters or rolls.
Sorry about the newbie questions, but I'm a newbie
I think I understand now. I went fishing for games that scanned over 262, and I noticed that "This Planet Sucks" weighed in at a constant 282 per frame. Out of curiousity, when you have frames that surpass 262, is there a standard method to even out the time? For instance, say I pared down my routines so that the maximum number scanlines in any given frame is 273. Would I (could I / should I) add garbage to the other frames until they also have 273 scanlines?
-
262 scanlines +-5% should be no problem. But they have to be constant.Thanks again for your help with this. I revised my code somewhat to try to get scanlines under control, and I just wanted to make sure I understood what you meant by "constant."
I spread my code across three frames. Now, when I do a frame-by-frame trace in Stella, I get the following results:
Frame1: 262
Frame2: 276
Frame3: 273
(...)
It runs fine in Stella and z26 defaults, but the variance is less than 5% and it varies at a the same rate throughout the program. Is this what you mean by constant? Or do you mean that does every frame needs to have the exact same number of scanlines to prevent rolling (i.e. every frame has 276)?
Cheers,
Jarod.
-
With all of that collision checking, you might have to break it up among multiple displays instead of checking all of them on a single frame (and/or optimize the code that exists within the loops).Thanks, Nukey. I was just staring at my code a second ago and thinking the same thing (about breaking it across several frames.) What I'm doing now definitely isn't very elegant.
-
262 scanlines +-5% should be no problem. But they have to be constant.Thanks, Thomas. This is extremely helpful, and it makes a lot of sense too. The funny thing is, I now know my suspicions about those "for-next" loops were correct. When I disable them all together, I maintain a constant 262 scan, and when I limit their iterations, the variance isn't nearly as large, which is probably why that 2_loop version worked okay in Stella.
Of course, that means I'll have to figure out a new way of testing those conditions, but it's incredibly helpful to know what sort of results to look for.
Cheers,
Jarod.
-
Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?Nope. Most likely the screen will roll on actual hardware.
Emulators are mainly written to emulate correctly written software. How they react on bugs, unless explicity implemented, is unpredictable.
Hmm... Well that's sort of helpful to know, but I suppose this brings me back to original nature of my question. After all, viewing the program on z26 doesn't show any obivous "bugs." So what I'm really asking is, does a baseline metric exist that programmers use to debug for cartridge? I mean, if emulators can't simulate true VCS performance via settings, is there a generally accepted list of benchmarks or guidelines on what to look for that may work in emulation but will be buggy on cartridge?
For instance, when I see wide trace variance in scanlines, what trace values I should aiming for (i.e 262)? Do benchmarks exist for framerate variance as well? Hope that makes sense.
Thanks,
Jarod.
-
Default Z26 didn't seem to have any of these issues, no matter how many loops I included.Both binaries display a rapidly varying number of scanlines. Try z26 with option -n and see what I mean.
Yes, I noticed that too. But if z26 doesn't seem to have a problem with that, does that mean that the actual VCS hardware won't either?
-
I think you're confusing graphical performance with CPU emulation performance. Most systems today are so ridicuously fast that having the CPU emulation in C++ or assembly is pretty much the same thing. The number of for loops isn't the issue. Stella does have some problems with certain TIA emulation issues, but it's being worked on (and isn't related to your problem)Thanks so much for your speedy response, stephena. I've attached two binaries to help illustrate the issue, and see if you can reproduce it on your end. I'm pretty new to emu's so I'm not exactly sure whether what I'm seeing is an emulation bug or not. Basically, the rate of the game at which the graphics update seems to jump, almost as if the framerate itself is changing while the game is in progress. In other words the code still crunches correctly, but the rate at which the screen refreshes isn't constant the way it is in Z26 defaults.
The only reason I mentioned my for loops is that when I recompile with a lesser number of my for loops, Stella seems to handle the code fine no matter what the graphics transport mode is. Here's what I'm seeing on my end with these two binaries and Stella defaults:
Armageddon_Complex_5_loops.bin
- Entire graphics display shudders
- The refresh rate jumps every two seconds, almost like a "hiccup" effect (sorry for the bad analogy, but I'm not sure how else to describe it)
Armageddon_Complex_2_loops.bin
- No shuddering
- Constant screen refresh rate.
When I use Open GL on the "5_loops" version refresh rate is constant, but the display still shudders. Again, none of these problems occur on Stella when I shorten the total number of for loops per drawscreen. Default Z26 didn't seem to have any of these issues, no matter how many loops I included.
System Specs:
- Windows XP Pro
- Pentium D 2.80GHz
- 2.0G RAM
- RADEON X1300 Series graphics adapter
Thanks again for for taking the time to respond. I guess since I was seeing a definite difference in the way Stella and Z26 were handling the same code, I wanted to know which would be better suited to debug for EPROM, but in no way was I suggesting that Stella was inferior to Z26 in emulation. If anything, I assumed the issue was with my code, and wanted to figure out which standard to optimize towards. Please let me know if I've left out any info that might be helpful.
Jarod.
-
I'm curious which emulator is more accurate to physical cartridge performance? Both have a variety of settings that seem to "fix" certain performance issues but is there a particular platform and/or settings that reliably emulates the physical system? The reason I ask is because I'd like to someday put a game on cartridge, and I've already run into some major performance differences in a game I'm working on.
In particular, I'm using three for-next loops to test for collisions with a game map. Each for-next loop runs five iterations per game loop, with the first five on one side of the drawscreen and the other ten on the other side. Default z26 settings run this code silky smooth with no performance problems, but Stella's defaults chew on it like burnt steak. But if I switch Stella's settings from "Software" to "Open GL" or limit the number of for loops from 5 to 2 it's fine. Unfotunately, limiting the number of for-loops is too, well, "limiting" and I don't trust Open GL's hardware accuracy.
If anyone has any insight into the most accurate form of emulation, or even a good metric to test hardware accuracy I'd be much obliged. Thanks in advance.
Jarod.
-
Oops The file will function properly, so no need to replace with the older version unless you want the comments (which describe the structure of the file and what the included asm files do.) What happened is I accidentally deleted the comments and that was a note to myself to recover the comments from an older version (which I didn't have with me at the time.)Aha! Thanks. So the includes are the same, then. I've been trying to figure out a possible bug with bankswitching and fixed-point math. It seems like when you try to do subtraction of fixed point variables with bankswitching on, the assembly fails on:
"--- Unresolved Symbol List
Sub44from88 0000 ???? (R )"
Is this a known issue?
Thanks for your help.
Jarod
-
I just realized that the version of the "bankswitch.inc" include that shipped with batari 1.0 is this:
; this file is screwed, I accidentally deleted the comments. Restore with version in .99b zip file. 2600basicheader.asm bB.asm std_kernel.asm startup.asm pf_drawing.asm pf_scrolling.asm std_routines.asm std_overscan.asm bB2.asm score_graphics.asm banksw.asm 2600basicfooter.asm
Does anyone have this version of the correct file? I sniffed around the web, but cannot find it. Any help would be much appreciated.
Thanks,
Jarod.
-
Thanks for the demo. Now we can get more multicolored sprites up on the screen instead of being stuck with just one. The flickering seems to be even less noticeable with 3 sprites, and with 3, one of the sprites doesn't look like it flickers at all, which is amazing.No problem. The cool thing is, with the phospor turned on full steam, there's no visible flicker at all. And even in the 70's range, the flicker is barely detectable. I'm already curious how this effect looks on an old-school TV tube... unfortunately I don't have an EPROM burner (or an old school TV).
The thing is, if you limit this loop to update only three sprites (like I'm doing in AC with a condition that tests whether or not all four sprites are present in a room) one of them actually won't be flickering at all. You just have to alter the loop to skip updating one of the sprites:
gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 if temp1 && myVariable=someValue then updateSprite4 if temp1 && myVariable<someValue then DrawFrame updateSprite2 temp1 = fspeed & 3 gosub Sprite2 goto DrawFrame updateSprite4 gosub Sprite4 DrawFrame drawscreen updateSprite3 gosub Sprite3 updateSprite1 gosub Sprite1 goto gameloop
-
I thought I'd post an example of the way I am flickering and animating my four sprites in "Armageddon Complex." I suppose these strategies could have been broken into two separate demos, but I think that together they might be useful in visualizing Atari gameloops in general.
First we select some kernel options. In this example, sharp-looking sprites are more important than missiles.
set kernel_options playercolors player1colors pfcolors set smartbranching on
We define some coordinate variables for our four noble sprites, as well as two additional variables to measure the framerate and the currentframe.
dim sprite1X = a dim sprite1Y = b dim sprite2X = d dim sprite2Y = e dim sprite3X = g dim sprite3Y = h dim sprite4X = j dim sprite4Y = k dim gameFrame = m dim fspeed = n
Next, initialize the game and give our sprites some starting positions.
playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ end COLUBK = $E0 sprite1X=30 sprite1Y=48 sprite2X=60 sprite2Y=48 sprite3X=90 sprite3Y=48 sprite4X=120 sprite4Y=48
Our gameloop is responsible for doing three main things.
- Count its own iteration (fspeed)
- Keep track of which frame all the sprites are in (gameFrame)
- Determine whether the current loop is an even or odd number
Inside the loop, fspeed tells the sprites to advance one frame every six gameloops. It also keeps track of which sprites player0 and player1 should draw. In this example, player0 draws sprites 1 & 4, and player1 draws sprites 2 & 3, and the subroutines that update them are balanced on either side of the drawscreen.
gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 if temp1 then updateSprite4 updateSprite2 temp1 = fspeed & 3 gosub Sprite2 goto DrawFrame updateSprite4 gosub Sprite4 DrawFrame drawscreen updateSprite3 gosub Sprite3 updateSprite1 gosub Sprite1 goto gameloop
The subroutines themselves don't do much in this sample, except to repostion the player sprites to the appropriate xy value, and instuct it to go to its animation routine.
Sprite1 player0x=sprite1X : player0y=sprite1Y : goto Sprite1Frames return Sprite2 player1x=sprite2X : player1y=sprite2Y : goto Sprite2Frames return Sprite3 player1x=sprite3X : player1y=sprite3Y : goto Sprite3Frames return Sprite4 player0x=sprite4X : player0y=sprite4Y : goto Sprite4Frames return
Finally, we animate the sprites by looking at the current value of gameFrame. Since gameFrame caps at 8, our sprites have a ceiling of 8 possible shapes in their animation. Of course, they don't have to have 8 different frames. And probably shouldn't, if you want to create the illusion that they are moving at different rates.
Sprite1Frames on gameFrame goto Shape1_1 Shape1_2 Shape1_3 Shape1_4 Shape1_4 Shape1_4 Shape1_3 Shape1_2 Sprite2Frames on gameFrame goto Shape2_1 Shape2_2 Shape2_3 Shape2_4 Shape2_1 Shape2_4 Shape2_3 Shape2_2 Sprite3Frames on gameFrame goto Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_2 Shape3_3 Shape3_1 Shape3_1 Sprite4Frames on gameFrame goto Shape4_1 Shape4_2 Shape4_3 Shape4_4 Shape4_5 Shape4_6 Shape4_7 Shape4_8 rem After this, you can draw all your purty graphics...
That's it! The attached source has some additional comments in it. I'm pretty new to batari programming, so I'm sure there are many other and better ways to do these sort of things. But I thought that maybe this general method might be useful for a few folks out there.
Cheers,
Jarod
- Count its own iteration (fspeed)
-
Okay, I have a heavily revised build. I go into a bit more depth about the changes on my blog, but here's the basic rundown:
- Flickering four sprites at 30hz (no visible flicker with phospor in Stella or x26)
- Generalized room drawing function to build objects from the data set no matter what order they are written in (which is key for building my level editor, as well as saving tons of ROM)
- Limited the max number of room objects to 5 (whilst fishing for extra variables, of course!
- Included semi-natural gravity and a "Jump" function for joyfire0, thanks to more awesome help from the amazing Mr. SeaGtGruff.
- Monsters now recognized floors and walls, turning around if they bump a wall or reach the edge of a platform.
- I took the teleporters out of this build so I could focus more on streamling my map drawing and flickering 4 sprites.
I optimized my code extensively, and this build moves much, much faster/smoother than my original newbie effort. However, I only have 33 bytes left in my game bank and I maxed out all my supercharger variables on this build, so for the next build I will definitely have to use extensive bit operations and *some* sort of bankswitching.
EDT: Whoops, wrong BIN. New one attached.
- Flickering four sprites at 30hz (no visible flicker with phospor in Stella or x26)
-
Thanks. Before I saw the game you're working on, I tried to have more enemies on the screen using the standard kernel, but no matter what I tried, it flickered too much. I could stand the type of flicker that you're game has, though. It doesn't make me want to rip my eyeballs out. I'll do a test demo after I'm done with the new VbB page.Thanks again.
No problem. I plan on posting my BAS file for this as soon as I can get the next build done. As I was telling someone else it moves really slowly in the currently posted build because of the way I was testing collisions. It's much "peppier" with the way I'm doing things now, and a lot more flexible in terms of how the map data is structured. I also included gravity and a jump for the next build, so if I can get the map functions solid it might be the beginning of a halfway decent platform-game engine.
-
Jrok this is fantastic! The demo was more fun than many games. It reminds me of Xenophobe, except that your game is fun.What else do you plan the hero to do in this game? If you gave up missiles for the multi-color graphics, you still will have a ball. And since you seem to do flickering really well, that gives you two balls....
Thanks Piggles!
I'm working hard at a new version of this. When I reviewed my code I realized I was doing some things in a pretty boneheaded way. In the next build everything will move much faster, and I've implented gravity and a jump function for the hero.
In total, I am trying to have a maximum of 6 objects per room (platforms, walls, doors or transporters) drawn out of my data array. Also some transporter pads will (hopefully) not just take him up and down, but also sideways and room-to-room. The problem I'm trying to solve right now was that in the original, I was serializing the playfield objects individually, instead of doing them on the fly with one function (that's also what was making everything update soooo sloooooowwww).
As soon as I get that solved, I'll probably add a shoot function for the hero (using the ball). At that point, I'll likely be all out of ROM in my main game bank, and will need to learn bank-switching to proceed with development.
By the end, I hope to have the hero do the following:
- Draw and holster his laser pistol (to switch between jumping and shooting)
- Select items from an inventory screen and use them (keys, shields, gadgets, etc)
- Tuck and roll to dodge things while on the move
- Interact with non-enemy sprites and background objects when he stands on their active x,y position.
- Die!
It's a lot to jam in, but I guess the whole thrust of my experiment is, once I get my map array working the way I want, to write a little level editor in some other language to see if I can make designing this sort of game simpler.
-
What are you doing to get three multicolored characters on the screen where one doesn't flicker at all and the other two don't seem to flicker that much? That seems like a useful thing to know how to do.Well right now I'm just using the playercolors player1colors option in the standard kernel, and using 30hz flicker for player1 to draw the two enemies.
gameloop fspeed = fspeed + 1 if fspeed=6 then gameFrame=gameFrame + 1 : fspeed=0 if gameFrame = 8 then gameFrame = 0 temp1 = fspeed & 1 updateHero player0x=x : player0y=y gosub Hero updateObs gosub AssignObs if temp1 then updateSprite2 updateSprite1 temp1 = gameFrame & 3 gosub Sprite1 goto DrawFrame updateSprite2 gosub Sprite2 DrawFrame drawscreen goto gameloop
So in the above, I set up a framerate (fspeed) that cycles at an interval of 6, and a flicker rate (gameFrame) that cycles at an interval of 8 and then use temp1 to determine whether the current loop is even or odd to update the approriate sprite.
In the "Hero", "Sprite1" and "Sprite2" subroutines, I do all of the marlarkey to update their x, y, collisions, etc, and also include some animation subroutines for each. For example
Hero if...goto HeroStand if...goto HeroKneel if...goto HeroLoop Sprite1 if...goto MutantLoop if...goto TentacleLoop if...goto OffScreen
Then I made all of my sprites right now have 8 frames of animation, whether the shape was actually "animating" or not.
HeroLoop temp3 = gameFrame on temp3 goto Hero0 Hero1 Hero2 Hero3 Hero4 Hero5 Hero6 Hero7 MutantLoop temp2 = gameFrame on temp2 goto Mutant0 Mutant1 Mutant2 Mutant3 Mutant4 Mutant5 Mutant6 Mutant7 TentacleLoop temp2 = gameFrame on temp2 goto Tentacle0 Tentacle1 Tentacle2 Tentacle3 Tentacle4 Tentacle5 Tentacle6 Tentacle7 OffScreen temp2 = gameFrame on temp2 goto OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0 OffScreen0
There are probably be better, cleaner ways to do this, but I found this has worked pretty good for me so far. At first I experimented with the bB multisprite kernel for awhile, but it seemed a little limited for what I wanted to do both visually and in terms of gameplay (though I think it would be great for a fast and furious two-player game).
Eventually I'll be flickering player0 as well, and probably do away with player colors and flicker a multicolor player sprite and up to one multicolor enemy or item, then use player1 to flicker two monotone enemies/items. The good news is that right now when I have the phospor turned up at 70 or above in x26 or Stella, there's absolutely no flicker at all, which is pretty neat to look at.
-
Just got a chance to check this out today. It's freakin great! That thing on the first stage looks like the Purple Tenticle (was it purple?) from the Maniac Mansion type games.Thanks man! LOL, I think there was actually a green one AND a purple one.
-
Maybe you should put a cap on the acceleration? That way the man will never fall too fast. Here's an example-- a=240 was the "fastest" value that didn't result in the man falling through the playfield.Michael
if a > 64 then if a < 240 then a = 240
Genius! You solved it with a single line!
You know, I was trying to do the something similar (cap the downward accelaration ), but I was trying to do it with an && operation, which thanks to your fix I now realize I've been grossly overusing. I also think I'm not quite "getting" negative numbers. In the above line, would 240 mean -24?
Anyway thanks again. This really helped a lot.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Check out this random maze demo
in batari Basic
Posted
You know, this demo brings to mind a question about scanline that's been haunting me lately. When I ran this demo in emulators while tracing scanlines, I noticed that whatever routine draws the random map causing the scanlines to leap suddenly, then return to 262 after the map has been drawn. I'm experiencing the same thing in my own project, when moving between screens. A couple of questions for anyone who can answer them:
1) Is this a problem - That is to say, if nothing in particular is going on your screen when the scanlines fluctuate, would it still cause problems on cartridge? For instance, I have a playfield drawing routine that operates when the player exits the left or right side of the screen. The frame that he exits on runs a DrawRoom subroutine that generates 340 scanlines, and the frame directly before the new pf appears generates only 16 scanlines. Then everything goes back to the constant 262.
2) If it IS a huge problem on cartridge, is there a way to minimize it (short of abandoning the subroutine, of course)?
Thanks,
Jarod.