Tricks for collision prevention

[pacgreg]

For my amazing idea I had to work, I need to use pfread alot on a weird DF#FRACINC, specifically for DF#FRACINC=100. Does anyone know any tricks to this before I lose the idea? How does the sprite grid compare to the playfield grid so I can check around an oddly sized sprite on an oddly sized playfield? If this works I can make this a really cool game, otherwise I'm going to be DooMed from the start.

Thanks

Greg

[+Atarius Maximus]

Posting your code and more specific details about your idea would be helpful. No guarantees that I can help personally but that would be helpful to anyone who may be able to.

[+Random Terrain]

Why can't you use 128?

[+Gemintronic]

Two things:

 

* You don't need to be 100 percent accurate. It's OK to plan out your playfield to have little details that are open and bigger areas that are solid where the calculated pfread happens.

* You can combine traditional playfield/player collision checks too for slightly better resolution when needed.

 

To deal with an oddly sized sprite on an oddly shaped playfield I keep the sprite at the center and pfread just the blocks directly above, below and to the sides. i also do a last minute playfield/player collision check to futher prevent problems.

 

This is using the standard kernel and SeaGtGruffs pfhscroll library so the code is of no use to DPC+ users. I'll just post the binary here as a demonstration. Note that it's still possible to get semi-stuck. This was an abandoned game concept

pfreadandcol.bin

[pacgreg]

Why can't you use 128?

What's significant about 128? Is that a resolution that lines up with sprite placement? If so that would be infinitely useful, and I can do with changing parts of the code to accomodate that.

[+Random Terrain]

What's significant about 128? Is that a resolution that lines up with sprite placement? If so that would be infinitely useful, and I can do with changing parts of the code to accomodate that.

 

Certain FRAC numbers create rows that are made up of uniform scanlines. You'll probably need to refresh the bB page for this link to work:

 

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

 

That's a direct link to the row examples. Be sure to check out the example program below those examples.

[+Philsan]

Two things:

 

* You don't need to be 100 percent accurate. It's OK to plan out your playfield to have little details that are open and bigger areas that are solid where the calculated pfread happens.

* You can combine traditional playfield/player collision checks too for slightly better resolution when needed.

 

To deal with an oddly sized sprite on an oddly shaped playfield I keep the sprite at the center and pfread just the blocks directly above, below and to the sides. i also do a last minute playfield/player collision check to futher prevent problems.

 

This is using the standard kernel and SeaGtGruffs pfhscroll library so the code is of no use to DPC+ users. I'll just post the binary here as a demonstration. Note that it's still possible to get semi-stuck. This was an abandoned game concept

Awesome demo!

Would it be possible to do something similar with DPC+?

I would like to do a similar game!

[+Gemintronic]

Awesome demo!

Would it be possible to do something similar with DPC+?

I would like to do a similar game!

 

The source for my 4-way scrolling engine is here:

http://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/

 

It relies on SeaGtGruffs pfhscroll library that was never updated to DPC+ The key would be to modify SeaGtGruffs code for support.

[pacgreg]

I tried to use 128 and pfpixel to line it up and it's way too big and nowhere near precise enough for what I'm trying to accomplish. I had an idea and made a single pixel sprite fly around the player, and that would work amazingly (I even have it set up) if it didn't need drawscreens to detect playfield, those drawscreens are what slows the game down to dead. Does anyone know how to maybe make that one pixel lpayer into a virtual sprite so I can move it around a lot for collision without eating all my other players?

[+Random Terrain]

I tried to use 128 and pfpixel to line it up and it's way too big and nowhere near precise enough for what I'm trying to accomplish.

 

128 is about as precise as you can get. If you want the playfield pixels to be larger, click on this link:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_frac_rows

 

Do you see the different example sizes? 88 rows, 44 rows, 22 rows, and 11 rows?