DPC+ Playfield questions for Robot Zed

[Sprybug]

Hey guys, I'm back again with more questions about how DPC+ does things with playfield data and what exactly I can do with it.

So far I'm able to use it as it was meant to. No problems. I love being able to define 4 separate screen quadrants with different resolutions, which I do take advantage of. The right 1/4 of the screen I have at a high resolution to act as a life/energy counter and inventory. The left 3/4 I use for the game and I use the vertical scroll technique. This means of course that I define the levels using the playfield: data table. This works just dandy, but with only 4K of graphics data to store and play with, this makes me limit my levels, especially since i use 22 line resolution (for a nice even 4x4 playfield block look) and with all the sprites/enemies I have in this game. So I thought of some ways I could possibly get around this so the game doesn't end up being so small.

I changed the game to act more like a fetch quest. Which means you enter the same levels to do different tasks, but even with that method, it still means i can only have 3 or 4 different levels in total. I was okay with this, but as I have continued my 20K of available program space started to get smaller and smaller the more I added, which also means that I can't do everything I want to do in this game. So now I'm reimagining it once again. I thought, why not turn it into a Rogue Like? Kind of like Rogue Legacy. Where every time you play a stage, it's different every time. I thought I could accomplish this by perhaps sectioning out the levels into different pieces and have the game arrange these sections into a complete level by random, so it'd be different every time. I, of course, would design the sections to all be interchangeable. However, the only method I know of in Batari DPC+ is using the playfield: data table. Now sure, I could get it to jump to certain parts of the table using the Data Fetchers, but I'd rather have the program look at different tables and then piece a bunch of the parts of the tables into one big table in DPC+'s display RAM, so I can scroll from top to bottom without having it have to jump around. Problem of course is that there is nothing in Batari that would allow me to do this. I could do some inline assembly to send data to the display memory of DPC+ to make a level before you start it, but I have a feeling that the format of this bank is done in a way where it constantly changes and it's just not stored there entirely to scroll through, like you would in a ROM Table. I had a look at in the debugger in STELLA and there were certain values I was looking for in the 4K DPC+ Display RAM that I know my playfield table stage would represent and I just wasn't seeing it.

 

So, I'm just curious to see if anyone would have any idea how I could do something like that, or if it is even at all possible!

[iesposta]

I can push a whole Playfield display from data statements in batari Basic.

You set a hi and low address which I found thru trial and error. Then an ARM command pushes 8 bits at a time.

Since it is bypassing basic's nice "Playfield:" command, you have to do it the strange way the hardware wants it, as in: it goes bottom row up, and the 2nd & 4th PF sections are reversed.

[freshbrood]

Can DPC+ handle graphic data tables? When trying to share graphics via:

 

bank 1

const frame10lo=#<frame10:const frame10hi=#>frame10

 

with

 

bank2

data frame10

%11000011

%11000110

%00000110

%11000000

end

 

 

It fails to compile every time I try. I get an error message something to the effect of "invalid syntax" or like it can't understand what I'm doing.

 

 

In a regular 32k bank game, these work just fine. (graphic tables being in last bank)

 

So, can DPC+ not handle/read these? Or is there a trick to putting them in the right order?

 

Can someone make a sample DPC+ program using shared sprite graphic tables in bbasic please?

[freshbrood]

Also, a list of STANDARD kernel commands that DO NOT WORK under DPC+ would be much appreciated, if someone can point me to one. That could be my problem as well.

[iesposta]

Also, a list of STANDARD kernel commands that DO NOT WORK under DPC+ would be much appreciated, if someone can point me to one. That could be my problem as well.

I learned bB DPC+ first as I joined when it was the latest new version.

So even though I went back to a the older non-DPC+ Multi Sprite kernel for my 4K FLAPPY game, I really can't help with older "commands".

 

It is easier to keep track of your program because of the constraints and coding in 4K banks.

I would always got lost programming in Atari 800XL Basic because you can do much more and end up with "spaghetti code" where you are totally lost.

 

I found it better to learn what the hardware can do and loosely how it does things.

You don't have to know the "machine code" because bBasic does the heavy lifting.

Then I think of code to do what I know the hardware can do.

 

I don't code in sharing data tables.

Object data tables in DPC+ are copied from ROM to RAM for the ARM computer running the DPC+ bankswitch kernel scheme.

"Objects" being 2 Player sprites, more than 2 is using the real Player1 for "Player 1 through Player 9".

If I need Player3 through Player7 to be the same graphic for a formation attack, you can code data for all of them at once:

Player3-7:

%00110011

%00110011

...

end

[+Random Terrain]

Can someone make a sample DPC+ program using shared sprite graphic tables in bbasic please?

 

The bB page already has one:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_shooting_nusiz

[freshbrood]

DELETE

Edited September 24, 2017 by freshbrood

[iesposta]

Is this what you are attempting?

The best programmers here have tried and failed:

 

http://atariage.com/forums/topic/229538-writing-player-data-dpc-in-stella/?hl=%2Bdpc%2B+%2Bplayer1pointerlo&do=findComment&comment=3069630

[freshbrood]

I guess I'm being overly ambitious as a first time noob programmer.

 

I noticed the part that says "HI byte greater than 127".. does this mean it would work keeping it under 127?

 

 

 

 

 

 

Also, in the standard kernel, what is the command to use multiple background colors with a solid playfield color?

Edited September 24, 2017 by freshbrood