wallaby

Hmm. I tried that (only 3 lines to comment out, right?) but the graphic gets corrupted when I change the index. There must be something else referencing the graphics from the index?

What is the syntax to change the 48x2 line colors on the fly? I'd like to animate the colors without having to animate the frame (using index for example.) Just because the frame is large and takes a lot of ROM space, but changing a color pallet is only a few bytes.

Well, putting input on alternate frames creates the same ugly effect that running drawscreen twice. Maybe if I pause input for two frames it will look better. But this seems like it's more work than just running drawscreen twice and has the same drawbacks. EDIT: Okay, solved this. I left the movement code in as is, but culled the more complicated collision detection. I also alternated processor intensive code and that finally got me on top! In addition to RT's code ON or OFF suggestion, I also put in a frame counter so code can once every other frame, every 3 frames, or every 4 frames. Hoping I can by with this without complicating anything further.

Ah, that's a good idea. I do use a few gosubs, but they're necessary. Otherwise the game would be too big and too difficult to manage. I don't think I have the ability to change anything fundamental like that with DPC+. One of the drawbacks of DPC+, I guess, but the pros outnumber the cons.

So I've finally hit a point where the poor Atari 2600 can't handle any more processing in a single frame. I've optimized it, but it still bounces a few frames over. Since I still have things like sound to add, I think this will only get worse. I disabled the score "noscore = 1" and that gives me a lot more processing - BUT, for some reason, the frames aren't set at 262 anymore. They change to 251. And still bounce around (but still below 262). I know it didn't do that before, but I'm so far along, I have absolutely no idea why it isn't syncing at 262 after disabling the score. At any rate, I decided to add another drawscreen in the mix and now the game runs at 30fps. This of course fixes the processing problem completely. But now, when I move my character, it leaves an after image. Only a few milliseconds, but its very irritating. Especially compared to how well it ran at 60fps. I wonder if this is because of the timing of the drawscreen? Actually, maybe the character is updating on the new drawscreen because I've changed the location in the preceding frame but it hadn't updated the drawn position. Hmm. Maybe I'll mess around with where I place this drawscreen. Anything I'm missing?

How do you test a 64k game on a real system? Does the Harmony cartridge work with games that size? Can you use DPC+ with this 64k option?

Any possibility you could create a Linux image that has everything all ready to go? Then all anyone would need to do is run the VM to get started. The annoying thing would be keeping the image up to date I guess.

Yes. I'd rather write in C than Basic, that's for sure. But it depends how involved it is getting a development environment set up. Being able to use a premium tool like Visual Studio would make much better Atari games in the future. That said, batari basic is really only a pre-compiler and everything ends up as assembly. A lot of my project has ended up as inline asm, which is a great feature and learning tool. C would be running on the ARM chip right? Does having to manage the interplay between the C code and assembly make it more difficult to get started? With batari basic and Sublime Text I've made a quick and adequate development environment where I can test my game on a Harmony Cartridge seconds after building it. It's not as powerful as a Visual Studio set up, but its great for batari basic. Where are the high resolution screens stored? Are we still limited by 32kb?

I've been adding an extra "drawscreen" calls in problem areas in my game. It seems to fix the problem most of the time, but what is the best practice? I have a situation where the game loops an indeterminate number of times and it could take longer or shorter. Do I just sprinkle more "drawscreen" in there, or do I actually have to let the kernel cycle through to the next frame on its own?

That makes perfect sense now! Thank you for the detailed answer. I'm using so many of your code snippets in my game now. The extra cartridge ram variables are invaluable to what I'm trying to do now. Playerpointers is built-in to DPC+. It offsets a base address by a few bytes depending on the player data. So it sort of already works as an index. What I'm using it for is to change sprite data based on the player. It's easy to specifically set the offset to whatever you need, but it got more difficult for me when I wanted to turn it all into a single function to save ROM space. It wasn't as efficient to write the function in bB because I needed the variables that bB uses for function parameters.

Okay! I got this. What I had to do was make the pointers a constant. So: const player2lo = <(playerpointers+2) Then I could: LDA #player2lo I tried so many different ways. So many wrong things! I started to question my resolve.

LDA <#(playerpointers+2) WORKS. LDA #2 STA temp1 LDA <#(playerpointers+temp1) DOESN'T WORK. How do I rewrite the top line so "+2" can be a variable? Still. writing. sprite. changer. While I'm here, what does < do? Left shift?

It looks like you can access bank 7 in the normal way which is the graphics bank. Hmm. I'll try putting some data sprites there.

I'm still wrangling with some aspects of DPC+. For example, if I set the player graphics likes this: player0: %1111111 etc. batari will take that information and store it in the graphics bank with a generated label. I don't know what the label will be called ahead of time. So I can't easily assign another sprite that graphics data. However, a label DOES exist, and if I knew what it was, I could easily assign it to other sprites. A work around is to create a data statement with the graphics data: data mysprite %1111111 etc. Now I can assign this data to another sprite. But - the caveat is that the data is stored in whatever bank you define it in and not the graphics bank. Can I explicitly place data in the graphics bank so I don't waste it?

I have rabbit holed so far down this it isn't even funny anymore. Your example works. So then I thought, why not make it so I store the lo and hi bits in data. Then I can use some fancy coding to select player 1 or 2 or whatever. Storing the lo bit: const player_0_lo = <playerpointers ;WORKS. data player_pointers_lo <playerpointers ;DOESN'T WORK end I thought it would be more elegant to change the player lo bit with a data table. Because you could type: player0pointerlo = player_pointers_lo[0] + 8 And that would work for player 0. Instead of having to use a constant e.g: player0pointerlo = player_0_lo + 8 But, after typing that out. I don't think it matters. You probably save more space using a constant anyway. As long as I'm not going crazy with animation frames constants would work, I guess. I keep getting dragged into a marathon battle with this game.

It's either a list of colors or sprite data. (Using DPC+ kernel) Imagine a situation where you want to re-use sprite data. If you use bB, you might set player0 to a sprite using the syntax "player0: %000000, etc" What if you want to then use that same sprite for player1? If you use the same syntax "player1: %00000, etc" you just duplicated the data. The more sprites you want to use, more this situation spirals out of control. So, you can set the sprite using the data format. Then you can reference that data for your players and it's only defined once. data skele %00111000 %01111100 %01111100 %01111100 %01101000 %01101000 %00010100 %00010100 %01111110 %01111110 %10111101 %10111101 %00111000 %00111000 %01000100 %01000100 end I don't know of any way to set this data to a player object in bB. player0: skele? player1: skele? But I know how it is set in ASM by examining the file generated by bB. So I have to either bypass bB using inline ASM or extend bB to use some new syntax. Modifying bB is much, much harder because the application is larger and I don't have a development environment set up for C. That leaves one option - inline asm.

This really solves the variable problem. And in good time too. I just ran out. I was going to use the stack but this is much easier to use.

Here is my macro currently. This works. But does it duplicate the code for every label I pass to it? If I pass "monster" or "monster2" or "monster3" is this code getting duplicated for each one? macro _change_sprite_color_player0 ;1 datalabel (myskele) asm LDX #<{1} STX player0color LDA #((>{1}) & $0f) | (((>{1}) / 2) & $70) STA player0color+1 end end

What I'm trying to come up with is an efficient way to change player sprites and colors in bB. I didn't want to use a macro because of the duplication of code. The overhead of a function isn't too much of a problem since I won't call it every frame, only occasionally. I understand the assembly to set a sprite color or pixel data in DPC+. The problem is I don't know how to pass my address as an argument to the function. Or how to pass a label as an argument. (Since they're 16-bit.)

Hmm. Maybe macros don't behave like I thought they did. I thought they sort of allowed you to programmatically duplicate code. But when I call the same macro twice, it looks like it acts more like a function. In that case, it shouldn't duplicate and using a macro is easier. Unless my interpretation is wrong.

This is basic ASM question. What I'm trying to do is use assembly (instead of a macro) to change the player sprites and colors to anything. change_player_color STA player0color STY player0color+1 LDA #16 STA player0height RETURN If I call the function this way: temp1 = change_player_color(flash_lo, flash_hi) This changes the color, but not the right way. It looks like it's just getting random data and all the lines are different colors. I'd like to simplify this so I only need to pass the label of the data object. Like: temp1 = change_player_color(flash_color) Another thing, is how can I manipulate something already in a register? Can I use other registers in an expression? LDA x + y? Can I manipulate the current register on the same line? LDA a + 1? I have this working with macros, but do macros duplicate your code for every permutation?

EDIT Fixed it. Here is the code adapted to bB function SetValue1 asm ; A = location 0-255 ; Y = value sta DF0LOW lda #$0f sta DF0HI sty DF0WRITE end return function GetValue1 asm ; A = location 0-255 sta DF0LOW lda #$0f sta DF0HI ;lda DF0DATA ; A is the return value end return DF0DATA function SetValue2 asm ; A = location 0-255 ; Y = value sta DF0LOW lda #$0e sta DF0HI sty DF0WRITE end return function GetValue2 asm ; A = location 0-255 sta DF0LOW lda #$0e sta DF0HI ;lda DF0DATA ; A is the return value end return DF0DATA I commented out the last LDA on the Get functions because of how I return from the functions. If I leave the LDA in, the return value is 1 off. If I comment it out, it works as expected in bB.

I only have one current project, but it reports DPC Ram = 603. I'll see if it changes as I add more code and stack manipulation.

256k is larger than most Nintendo games, isn't it? You could have more complex games, but part of the appeal of Atari development is that you have a small space to make something fun. I'd use extra space for more sprites and backgrounds mostly.

Regarding the current stack, I feel it's great for storing information that doesn't change every frame. You can use it like 256 extra variables this way. It's funny, before I starting writing an Atari 2600 game, 256 bytes would have been completely inconsequential to me.