RB+ Manic Miner :)

[sh3-rg]

but got a bit hung up this morning on where SCRBUF was coming from.

 

I guess it's a RAPTOR constant ?

It is for the "text layer" or "particle buffer layer" - GGN is assuming you're using this 4-bit object for your background platforms/level layout. If you're not you simply have to grab the address of the source gfx data (that pointed to by your backdrop object) and adjust your calculations when peeking to suit bitdepth.

 

It also hadn't clicked that each item in the OP is a layer in it's own right - and that makes things easier to understand.

If you wish to think of it that way and it helps, sure. The display on screen is produced a line at a time effectively as a collage, or rather a series of thin collage slices. As I said above, design your game using the features that raptor makes easy for you and everything becomes easier. You can use CD 1 vs 1, 1 vs many, many vs many. It's very simple, clean and efficient as the GPU takes care of it for you.

 

Does the size of the graphic in the OP affect the performance or is it just number of items in the OP that causes slow down ?

Consider how the screen is produced. For every line of the display, the OL is traversed and the image built up for all objects that appear in that line*. Ideally you will want to limit this number where possible. Object height obviously impacts as well as a taller object will appear in more lines. Your plan to have a single background image for the whole level layout obviously saves heaps of bandwidth here but with the added complexity of hand-coded CD.

 

IMO, when it comes to a game like Manic Miner, people might expect pixel-perfect collision detection if they're used to experiencing that in previous games. Bounding box might either feel a bit unfair or too cheap when the player sprite animates and phantom collisions are seen or toes poke through platforms etc.

 

*You can use branch objects for OL efficiencies, but that's something you might only want to bother with towards the end of a project if there's a fine line between a locked framerate or the OP shitting the bed.

 

EDIT: If I were making a game of this type, I'd definitely stick with doing everything object-based. Clearly having a screen full of speccy-like 8x8 objects would be unrealistic - the OP would go into meltdown. But with some clever object design, use of much more chunky, larger but still reusable lumps of platform, there would be a happy compromise between simplicity of coding, object count and level design. Pixel-perfect collision detection would still be a challenge and it might be that I'd have to have to adjust the hitbox per frame to suit the gfx (but more sensibly, just design the graphics and animation in a way that bounding box works well).

Edited May 10, 2017 by sh3-rg

[ggn]

Cheers GGN - will try this out in a bit and how did you guess I like a bit of ZX Speccy coding

Well, the xor thing was a dead giveaway

 

I did look through your map code and had come to the conclusion that the LPEEK section was where I needed to concentrate but got a bit hung up this morning on where SCRBUF was coming from.

 

I guess it's a RAPTOR constant ?

No, it's just the start of the screen object in the drawmap example. You can replace it with the start address of how you call your object.

 

It also hadn't clicked that each item in the OP is a layer in it's own right - and that makes things easier to understand.

 

Does the size of the graphic in the OP affect the performance or is it just number of items in the OP that causes slow down ?

Size of graphic, how many lines it is, how many bits/pixel - they all matter. The more severe limitation is how many objects can be rendered in the same line(s). I.e. if you place 100 sprites roughly around the same y coordinates, cogs will be spat.

 

Your P.S.3 suggestion is kind of where i've go to

Anyhoo, i'll have a play and probably be back with waaaay more questions.

 

Cheers

Yup, that's also quite legit for most stuff! Although I would suggest you use objects for the other collideable stuff...

[saboteur]

I've been mucking about with screen locations and have a question - which is probably realy dumb - but here goes anyway

 

So I can set an objects x,y coorinates with standard integer values using

RSETOBJ(ABC,R_sprite_x,(50<<16))
RSETOBJ(ABC,R_sprite_y,(50<<16))

But

RGETOBJ(ABC,R_sprite_x)
RGETOBJ(ABC,R_sprite_y)

does not return the expected ( at least to me ) corresponding integer value E.G 50 & 50

[saboteur]

Never mind - just divide it by 65536 - it's late.

[ggn]

Or...

 

If you use the [/rlist] style of fiddling with objects you could rewrite the above as:

 

rlist[ABC].x=50<<16
rlist[ABC].y=50<<16
my_x=rlist[ABC].x>>16
my_y=rlist[ABC].y>>16

or even better:

 

rlist[ABC].x_=50
rlist[ABC].y_=50
my_x=rlist[ABC].x
my_y=rlist[ABC].y

Look ma, no shifts x_, y_, xadd_, yadd_ only read/write the integer part so no need to do anything there!

[Welshworrier]

Wouldn't the last x and y from there be the x_ and y_ versions (I take it they are overlays of the x and y integers)

[ggn]

Wouldn't the last x and y from there be the x_ and y_ versions (I take it they are overlays of the x and y integers)

From include/raptor.h:

  union   {	short x_;int x;		};
  union   {	short y_;int y;		};
  union   {	short xadd_;int	xadd;   };
  union   {	short yadd_;int	yadd;   };

so you either use the integer coordinate as word or the full 16.16 fractional coord, depends on your use case. I just mentioned this because I see people still get confused over the shifts when they use the full 32-bit format. Edited May 22, 2017 by ggn

[Welshworrier]

I'd guessed

just you were storing using the Union version but were reading using the full without the shift.

I.e. rlist[ABC].x_ instead of rlist[ABC].x

Edited May 22, 2017 by Welshworrier

[saboteur]

I was playing around with object collision last night and have a few questions/issues.

If my platform is, for example, 48px * 16px but i just want the hit to be triggered for the top line of pixels I set my hit box paramters to 48/2 and 1/2 in RAPINIT.

That however doesn't work as per my expectation so then of tried changing the y offsets, but still don't get the result expected.

What is the correct way to do this or is this not possible.

Also whilst my platforms are 16px high i'm only using the top 8px but again setting the vertical hit box to 8 gives odd results, but I expect this is due to the y offset again ?

cheers

[+CyranoJ]

If my platform is, for example, 48px * 16px but i just want the hit to be triggered for the top line of pixels I set my hit box paramters to 48/2 and 1/2 in RAPINIT.

 

y-offset to -7 (up 7 from the middle)

 

hitbox size is 24(x) and 1(y)

[saboteur]

Thanks for the reply CJ

 

Just to sure then, the hbox is in bytes ? and the vbox is in pixels ?

 

so should the format be 24/2 for a 4bpp image for the hbox

[+CyranoJ]

No, they're both in pixels.

 

Image bit depth doesn't come into this at all, only the image size. The hitbox is the number of pixels from the center of the object, which is why there is also an offset value so it can be moved.

 

There is also provision for multi-hitboxes per object, so for example, you could define the 4 corners of a rectangle as the hitpoints, while the rest is 'safe'.

[saboteur]

Thanks again CJ, that would explain a lot of the results i'm getting