How do virtual sprites work?

[pacgreg]

I need to move a single player around many times to check for things, but the need to do a drawscreen between each movement slows the game down too much, how do virtual sprites move back and forth to put the two on screen in a single drawscreen? How do I make my own? I attached part of the game I'm working on to show what I'm trying to do, but the necessary drawscreens are slowing it down to be unplayable. I tried to accomplish the same task with pfread but that's too big; they need to be a single pixel.

Example.bas

[+Random Terrain]

Have you checked out this example program:

 

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

 

There's no need to have 5 million drawscreens.

 

 

Also, here is your program with most of the drawscreens removed:

 

pacgreg_2014y_02m_01d_1231t.bin

 

pacgreg_2014y_02m_01d_1231t.bas

[pacgreg]

The drawscreens need to be there otherwise the moving pixel does not detect anything as it follows its path(unless there is a way around that), it just stays in that final position.

[pacgreg]

I jsut realized, do all 9 players have a missile? because that would make it much easier/faster.

[+Random Terrain]

The drawscreens need to be there otherwise the moving pixel does not detect anything as it follows its path(unless there is a way around that), it just stays in that final position.

 

You probably just need to improve your code.

 

 

 

I jsut realized, do all 9 players have a missile? because that would make it much easier/faster.

 

Nope. Everything available is displayed in this example program:

 

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

 

Go there, try the .bin file using Stella, then look at the .bas file.

[pacgreg]

OK I got it, I can use the 13 objects, each to a horizontal row of the circles to avoid flicker issues, at the beginning of the program and reassign them later in the code.

[pacgreg]

Another question, do offscreen collisions register? Like if I took that program that I had on here and bumped the map looking thing to just below the screen, would everything still move around and collide correctly?

[+Random Terrain]

Another question, do offscreen collisions register? Like if I took that program that I had on here and bumped the map looking thing to just below the screen, would everything still move around and collide correctly?

 

Somebody like RevEng or SeaGtGruff would have to answer that.

[SeaGtGruff]

I haven't looked at your code to see what you're trying to do, but collisions only register if they occur while the screen is being drawn-- i.e., when the TIA is drawing a pixel at a specific spot on the screen, it's able to detect when two or more objects are overlapping at that position (because it's being told to draw them at the same time), in which case it sets the collision flag(s) for the objects in question. So if you move the objects below the screen-- by which I assume you mean behind the score-- the collisions can't occur, since the objects aren't drawn down there.

[+RevEng]

Another question, do offscreen collisions register? Like if I took that program that I had on here and bumped the map looking thing to just below the screen, would everything still move around and collide correctly?

If it's below the screen, the display kernel never actually draws it, so it can't collide with anything.

[+batari]

Well, I'll just say that some collisions rely on drawn objects but some do not. In this manner, DPC+ works differently than other kernels. DPC+ uses ARM code to detect sprite-to-sprite collisions and does this in a pixel-perfect manner even when the sprites are not displayed due to flicker, and (although I haven't verified) might work off-screen too - it depends on when I stopped checking for collisions.