Jump to content

Photo

New Prototype - Driving thing


128 replies to this topic

#26 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Mon Aug 24, 2015 9:28 AM

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, Mon Aug 24, 2015 9:41 AM.


#27 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Mon Aug 24, 2015 11:16 AM

Alright already, renamed to powaset hence forth :).

#28 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,323 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Mon Aug 24, 2015 3:22 PM

Pole Position 200000 ;-)



#29 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 4:11 AM

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, Tue Aug 25, 2015 4:13 AM.


#30 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Tue Aug 25, 2015 6:08 AM

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 :).

#31 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 6:41 AM

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.



#32 ggn OFFLINE  

ggn

    Stargunner

  • 1,357 posts
  • Location:Athens, Greece

Posted Tue Aug 25, 2015 7:42 AM

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, Tue Aug 25, 2015 7:43 AM.


#33 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 7:46 AM

...

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!


  • ggn likes this

#34 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 8:53 AM


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:



#35 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 9:20 AM

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, Tue Aug 25, 2015 9:21 AM.


#36 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Tue Aug 25, 2015 1:40 PM

Did the performance take a leap at all?



#37 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 2:21 PM

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. ;)

Attached Files

  • Attached File  road.abs   294.62KB   14 downloads

Edited by Sporadic, Tue Aug 25, 2015 2:25 PM.


#38 CyranoJ ONLINE  

CyranoJ

    Quadrunner

  • 5,320 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Tue Aug 25, 2015 3:00 PM

 

- 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.



#39 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Tue Aug 25, 2015 3:00 PM

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 :)



#40 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,818 posts
  • Busy bee!
  • Location:England

Posted Tue Aug 25, 2015 3:03 PM

cross your fingers you don't clash with the object list copying it does every frame.


Blitter mutex :P.

#41 CyranoJ ONLINE  

CyranoJ

    Quadrunner

  • 5,320 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Tue Aug 25, 2015 3:05 PM

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.



#42 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Tue Aug 25, 2015 3:06 PM

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.

 

Spoiler

 

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, Tue Aug 25, 2015 3:13 PM.


#43 CyranoJ ONLINE  

CyranoJ

    Quadrunner

  • 5,320 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Tue Aug 25, 2015 3:12 PM

Runs great on the Jaguar - full speed!

 

However I think one of the Y-positions has a rounding error:

 

Attached File  road.png   603.6KB   13 downloads

 

[EDIT]

 

Free sun SFX from camera lens - JJ would be proud.


Edited by CyranoJ, Tue Aug 25, 2015 3:14 PM.


#44 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Tue Aug 25, 2015 3:15 PM

 

Runs great on the Jaguar - full speed!

 

However I think one of the Y-positions has a rounding error:

 

attachicon.gif road.png

 

Sega Blue Sky and a big ol' sunshine. Now that's powa!



#45 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,818 posts
  • Busy bee!
  • Location:England

Posted Tue Aug 25, 2015 3:33 PM

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.

#46 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 4:33 PM

Runs great on the Jaguar - full speed!

 

However I think one of the Y-positions has a rounding error:

 

attachicon.gifroad.png

 

[EDIT]

 

Free sun SFX from camera lens - JJ would be proud.

It looks 64 times better with the sun!!!!  ;)



#47 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Tue Aug 25, 2015 4:36 PM

btw...

 

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

Dammit I wish I had the chance to try it tonight.  I wanna see it lol

 

I'll have to check out that dodgy green line too



#48 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Wed Aug 26, 2015 7:08 AM

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.

Attached Files

  • Attached File  road.abs   294.67KB   12 downloads


#49 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 3,388 posts
  • doge + tie = dothemath
  • Location:BOLTON, England

Posted Wed Aug 26, 2015 11:37 AM

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, Wed Aug 26, 2015 11:39 AM.


#50 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • Topic Starter
  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Wed Aug 26, 2015 11:54 AM

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 :( 





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users