Jump to content
IGNORED

New Prototype - Driving thing


Sporadic

Recommended Posts

Holy shit, did all this happen while I was at work... WTF?!

Also, powARSEt - now do you see?

EDIT: psst....

Something like powarset(pointer to values, start object, offset, no of objects to change).

Edited by sh3-rg
  • Like 2
Link to comment
Share on other sites

Alright already, renamed to powaset hence forth :).

 

I have given the two new commands a go but neither seems to have any effect on the sprite.

 

I'm definitely using master this time lol. It all compiles now, just the sprites don't move.

 

I've tried;

powaset(startline, R_sprite_x, 150, xpos)
	
powadiff(startline, R_sprite_x, 150, xpos)

Where;

startline is the index of the object (the object has its count set to 150)

xpos is an array[150] of ints with each value set to a different int.

 

I have tried setting the array values (for testing purposes) as follows;

xpos[i] = i<<16

and

xpos[i] = i

Where i=0 TO 149

 

EDIT: I've taken out all other RSETOBJ lines that set the addx values :) So shouldn't be anything fighting for position.

 

Hopefully i'm not being stupid again.....

Edited by Sporadic
Link to comment
Share on other sites

Okay well, I tried to use powaset as a replacement to rsetobj and it didn't work either! So I just committed something that at least makes it work as rsetobj. It should work for multiple objects too. Give it a try :).

hmm, i afraid i'm still not seeing any movement. I also tried an array with 1 item (to simulate rsetobj) and that didn't work either.

Link to comment
Share on other sites

Well, I just modified shootbang.bas a bit:

 

dim arse%[50] 'put this one at the top of the file

 

Then in check_pad:

 

'RSETOBJ(ship,R_sprite_x,ship_pos-(2<<16))

arse[0]=ship_pos-(2<<16)

powaset(2,R_sprite_x,1,strptr(arse))

RSETOBJ(ship,R_sprite_gfxbase,ship_gfx_loc+ship_gfx_size)

ENDIF

 

IF pad1 BAND PAD_R AND ship_pos<(208<<16) THEN

'RSETOBJ(ship,R_sprite_x,ship_pos+(2<<16))

arse[0]=ship_pos+(2<<16)

powaset(2,R_sprite_x,1,strptr(arse))

ENDIF

 

With the old basic_functions.o the ship didn't move left/right (but would change graphic). It does with this. Does that work for you? If yes then I would assume you're doing something wrong.

Edited by ggn
  • Like 2
Link to comment
Share on other sites

...

powaset(2,R_sprite_x,1,strptr(arse))

 

With the old basic_functions.o the ship didn't move left/right (but would change graphic). It does with this. Does that work for you? If yes then I would assume you're doing something wrong.

Yep looks like i'm doing it wrong. I'm not using strptr(arse)..... I'm just passing arse..... so to speak

 

I will try give that a go instead, thank you!

  • Like 1
Link to comment
Share on other sites

 

With the old basic_functions.o the ship didn't move left/right (but would change graphic). It does with this. Does that work for you? If yes then I would assume you're doing something wrong.

Yep, working now! yay!

 

Nice one. I'll give it a proper go now.

 

:thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup:

  • Like 1
Link to comment
Share on other sites

So I removed horrible nasty for i=0 to 149 filled with RSETOBJ commands and other crap to this;

IF dir > 0 THEN
	powadiff(startline, R_sprite_x, 150, strptr(roadx))
ELSEIF dir < 0 THEN
	powadiff(startline, R_sprite_x, 150, strptr(roadx2))	
ENDIF
	
IF dirv > 0 THEN
	powadiff(startline, R_sprite_y, 150, strptr(roady))
ELSEIF dirv < 0 THEN
	powadiff(startline, R_sprite_y, 150, strptr(roady2))	
ENDIF

No loop needed for that any more.

 

roadx stores the positive speeds and roadx2 stores the negative speeds. (same for roady and roady2)

 

Might need to iterate the array to adjust the values for slow and fast corners, but not sure yet.

 

EDIT: reading that back, I need to use some useful variable names lmao

 

Thanks for the awesome

Edited by Sporadic
  • Like 2
Link to comment
Share on other sites

Did the performance take a leap at all?

I'm not sure. The emulator was fast anyway.

 

But, I think it has, because the stuff it's now doing probably would have slowed it down more.

 

Attached is the latest version. I've not tested this on real Jag yet, but it will be more noticeable on that if it's faster than the previous version.

 

Changes in this version;

 

- Horizon moves up and down with the road (kind of 1 level paralax effect - could add a load more)

- You can move forwards!!!!! B to speed up, A to slow down.

- Code is now using arrays to store values and these are being "POWA-PUSHED" to Raptor. In the main loop there isn't a single FOR loop.

 

The road is animated with a 3 frame animation (badly drawn). I started down the colour cycle route but it actually ended up being more of an arse than I thought because the horizontal "outrun stripes" are not all evenly spaced due to perspective. I kept the stripy road, but it could actually be anything now. The animation is pretty crap as the 3rd to 1st frame jumps due to my very quick paintshop pro skillz. If I took more time then it would definitely be more fluid.

 

 

Road animation discussion;

If you think back to how I got this working, there is a source 320x150 px road image. This is then used to fuel the GFXBASE for 150 sprites each set to 320x1 px using;

dim gfxroad%
gfxroad=RGETOBJ(road,R_sprite_gfxbase)

FOR i = 0 TO 149
	roadgfx[i] = gfxroad+(i*320*1/2)
......

I was kind of hoping (knowing that it wouldn't) that if the source image had an animation, then the 150 sprites each pointing to a 'scanline' would inherit the animation. This would mean I could just vary the speed of the source image animation and all the other sprites would just work.

 

However, it didn't work. I guess because the 150 scanlines are pointing to the address of the 1st frame, not what you see on the screen.

 

What I then did was to store the address for each frame in 3 arrays like so;

roadgfx[i] = gfxroad+(i*320*1/2)           '1st frame
roadgfx2[i] = gfxroad+((150+i)*320*1/2)    '2nd frame
roadgfx3[i] = gfxroad+((300+i)*320*1/2)    '3rd frame

Then during the main loop, I just pick which array to pass to POWASET for the GFXBASE of the 150 sprites. So, i'm managing the road animation frames myself by cycling through the 3 arrays.

 

I guess my ultimate question is if there is a way to have the scanline sprites automatically update based on the animation frame of the source image. Or is the way i've done it the only real solution?

 

Thanks for reading and happy driving. ;)

road.abs

Edited by Sporadic
  • Like 3
Link to comment
Share on other sites

 

- Code is now using arrays to store values and these are being "POWA-PUSHED" to Raptor. In the main loop there isn't a single FOR loop.

 

 

If you pre build 320-ish arrays for all the x-positions of the road, you only need to calculate the y-values - this should be even faster.

  • Like 1
Link to comment
Share on other sites

Yeah, they are all separate objects and have their own properties (btw, the grass scroller in uFLY works the same way, splices up the original for each consecutive lump as new objects. There's only 7 regions though, not 150 :D ).

 

Your way of handling it seems right enough. You could read up on the blitter, POKE the heck out of it, zap new gfx to your road address and cross your fingers you don't clash with the object list copying it does every frame. That would be a fun experiment :)

  • Like 1
Link to comment
Share on other sites

Yeah, they are all separate objects and have their own properties (btw, the grass scroller in uFLY works the same way, splices up the original for each consecutive lump as new objects. There's only 7 regions though, not 150 :D ).

 

Your way of handling it seems right enough. You could read up on the blitter, POKE the heck out of it, zap new gfx to your road address and cross your fingers you don't clash with the object list copying it does every frame. That would be a fun experiment :)

 

I can add a flag to disable the blitter for the OL copy in the VBlank, and use the CPU to copy the list - so if you have a case where using the blitter in the main code would improve speed you wouldn't have this problem.

  • Like 1
Link to comment
Share on other sites

btw...

 

Attached is the latest version. I've not tested this on real Jag yet, but it will be more noticeable on that if it's faster than the previous version.

 

I ain't telling you what it's like. You need to find this out for yourself.

 

 

 

no, honestly, not telling

 

 

nope

 

 

still not

 

 

seriously!

 

 

LOOK! NO, OK!

 

 

*BZZZZZZZZZZZZZZZT*

 

 

yeah, it's fucking fast :D

 

 

 

 

 

 

 

 

 

btw, turning and speeding up/slowing down seems a little iffy.

 

there's one set of y-values that leaves a green line.

 

umm... yeah, this is awesome :)

 

and make that rock like 3 or 4 times wider and stick it on the same x-pos as the top line, I want to get a feel for ripping around those corners!

Edited by sh3-rg
  • Like 3
Link to comment
Share on other sites

I can add a flag to disable the blitter for the OL copy in the VBlank, and use the CPU to copy the list - so if you have a case where using the blitter in the main code would improve speed you wouldn't have this problem.

How about exporting the mutex variable from RAPTOR and having a function to call that configures the blitter as an interrupt source and installs a suitable interrupt handler that clears the flag when the interrupt fires. That way if the flag is set in VBLANK, use the CPU otherwise use the blitter for the OL.

Link to comment
Share on other sites

Had a play today, minor update attached.

 

This includes a smooth road animation courtesy of sh3 :) :thumbsup: :thumbsup: :thumbsup: :thumbsup:

 

Been looking at getting the horizon scrolling horizontally depending on the speed you are travelling and the tightness of the corner. Not quite right yet so i've removed from this version.

 

Not had chance to look at the green line and dodgy speed up/down stuff yet.

road.abs

  • Like 2
Link to comment
Share on other sites

Unfortunately something is a touch wrong on hardware - if the road is in the upper possible areas (overlapping the backdrop), the OP is tearing, meaning too much is being asked of it. Maybe some of the additions you were adding are still active but doing nothing visible, but taking their toll at that point.

 

It definitely seems to be running at 60fps when the road is down bottom. I've had stuff that, when it couldn't quite make 60fps, began to tear and arse the display... but actually having more work to do dropped it a full, consistent further frame and the tearing was gone, it was just crappy 30 frames.

 

Just to check, your road objects are all set to opaque, same as backdrop?

Edited by sh3-rg
Link to comment
Share on other sites

Unfortunately something is a touch wrong on hardware - if the road is in the upper possible areas (overlapping the backdrop), the OP is tearing, meaning too much is being asked of it. Maybe some of the additions you were adding are still active but doing nothing visible, but taking their toll at that point.

 

It definitely seems to be running at 60fps when the road is down bottom. I've had stuff that, when it couldn't quite make 60fps, began to tear and arse the display... but actually having more work to do dropped it a full, consistent further frame and the tearing was gone, it was just crappy 30 frames.

 

Just to check, your road objects are all set to opaque, same as backdrop?

Thanks for the feedback. I'll have to check it all.

 

Probably no time tonight though :(

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...