sh3-rg Posted August 24, 2015 Share Posted August 24, 2015 (edited) 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 August 24, 2015 by sh3-rg 2 Quote Link to comment Share on other sites More sharing options...
ggn Posted August 24, 2015 Share Posted August 24, 2015 Alright already, renamed to powaset hence forth . Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted August 24, 2015 Share Posted August 24, 2015 Pole Position 200000 2 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 (edited) 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 August 25, 2015 by Sporadic Quote Link to comment Share on other sites More sharing options...
ggn Posted August 25, 2015 Share Posted August 25, 2015 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 . Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted August 25, 2015 Share Posted August 25, 2015 (edited) 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 August 25, 2015 by ggn 2 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 ... 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! 1 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 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. 1 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 (edited) 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 August 25, 2015 by Sporadic 2 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted August 25, 2015 Share Posted August 25, 2015 Did the performance take a leap at all? Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 (edited) 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 August 25, 2015 by Sporadic 3 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted August 25, 2015 Share Posted August 25, 2015 - 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. 1 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted August 25, 2015 Share Posted August 25, 2015 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 ). 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 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 25, 2015 Share Posted August 25, 2015 cross your fingers you don't clash with the object list copying it does every frame. Blitter mutex . Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted August 25, 2015 Share Posted August 25, 2015 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 ). 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. 1 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted August 25, 2015 Share Posted August 25, 2015 (edited) 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 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 August 25, 2015 by sh3-rg 3 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted August 25, 2015 Share Posted August 25, 2015 (edited) Runs great on the Jaguar - full speed! However I think one of the Y-positions has a rounding error: [EDIT] Free sun SFX from camera lens - JJ would be proud. Edited August 25, 2015 by CyranoJ 2 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted August 25, 2015 Share Posted August 25, 2015 Runs great on the Jaguar - full speed! However I think one of the Y-positions has a rounding error: road.png Sega Blue Sky and a big ol' sunshine. Now that's powa! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted August 25, 2015 Share Posted August 25, 2015 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. Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 Runs great on the Jaguar - full speed! However I think one of the Y-positions has a rounding error: road.png [EDIT] Free sun SFX from camera lens - JJ would be proud. It looks 64 times better with the sun!!!! 4 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 25, 2015 Author Share Posted August 25, 2015 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 26, 2015 Author Share Posted August 26, 2015 Had a play today, minor update attached. This includes a smooth road animation courtesy of sh3 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 2 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted August 26, 2015 Share Posted August 26, 2015 (edited) 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 August 26, 2015 by sh3-rg Quote Link to comment Share on other sites More sharing options...
Sporadic Posted August 26, 2015 Author Share Posted August 26, 2015 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.