Sporadic

Yeah there is a sky object behind the mountains. But the mountains aren't transparent yet. But in the future I would want the mountains transparent so they can fly around on top of the sky. Maybe even another layer of parallax would look cool too. I haven't bothered deactivating the road lines yet. when you are going "uphill" when they are all visible there is no overlap. However, they do start overlapping as you go level and then downhill. Unfortunately isn't not going to be very performant to check if each line is below a y value to disable/move it as i'd have to iterate all the lines (although only the top 30 probably overlap the most). Originally I did allow the downhill to go further, but there was far too many lines overlapping then and half of them disappeared - so I restricted the downhill movement.

Bummer I might get chance tonight to have a look. I wonder if I can clip the horizon mountain graphic at the road height or animate it up/down rather than have it sit behind the road lines.

little update. Resized some stuff and removed transparencies from everything. Hopefully it will perform smoother now on the Jag. Included some really bad horizon scrolling in this. (Hopefully patches will help here) If you turn to the left then it's nearly correct. If you turn right then the sprite vanishes forever and you see into a black hole. I need to slow it down as it moves way too fast at slow speeds and small corners but hey ho. You also need to be moving for the horizon to move (realism here people). road.abs

I have a feeling even with one list, making the first object inactive kills everything else. Not tried it recently so don't quote me on that

I highly recommend reading the tutorials on the website if you haven't already. http://reboot.atari.org/new-reboot/rbplus/

Thanks for the feedback. I'll have to check it all. Probably no time tonight though

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

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

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

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

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

Yep, working now! yay! Nice one. I'll give it a proper go now.

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!

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.

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

Could my day start any better

ok, might be my bad. I just checked the rbasic.h in my basic folder and its the 1.2 version (not today's master one). So I think I downloaded master, came across the 3 non-compiling projects, changed to 1.2 to test that, still found the 3 non-compiling projects, reported to you, then tried the new powa commands. Forgetting to go back to master!!!! So i'm sorry, looks like my issue. I've not retested yet, but my rbasic.h looks correct now. Cheers

I copied my project into the new rb+ download. Then copied the rapapp.s from one of the tutorials into my project. So it should have been using the include fokder fron the git download. I will double check though.

Hi, I just tried to give these 2 new commands a go and get a build error. Translating .bas file to C... Compiling C code... C:\Rik\basic\PROJECTS\road\build\road.C: In function 'void basicmain()': C:\Rik\basic\PROJECTS\road\build\road.C:206:46: error: 'powadiff' was not declared in this scope Build error! Translating .bas file to C... Compiling C code... C:\Rik\basic\PROJECTS\road\build\road.C: In function 'void basicmain()': C:\Rik\basic\PROJECTS\road\build\road.C:206:46: error: 'powarset' was not declared in this scope Build error! I copied my project folder into the new basic\projects from the latest version. I then copied a rapapp.s out of an existing example (not one of the failing ones) and into my project folder. I'm calling it like this; powarset(startline, R_sprite_xadd, 150, xpos) and have also tried; powarset(startline, R_sprite_xadd, 150, *xpos) where startline is an int pointing to the first sprite and xpos is an array[150] of ints. I wasn't sure how to pass the pointer for the array of values to the new commands, I tried both the above. Not sure if that's related to it not compiling. Thanks

Hi, I've just tried 1.2 and master branches and a couple of the example projects error on build. For example, I tried starfield and got the following error; Assembling raptor skeleton... Translating .bas file to C... Compiling C code... Linking things... UNRESOLVED SYMBOLS Audio_Play (basic_functions.o) Input_Read (basic_functions.o) Build error! It looks like the same error for each one that fails. The ones that don't compile for me are; 2lists crytest starfield Hope that helps

lmao love the name. Going to name all my variables at work today starting with Powa... You are a machine, thank you

RMODOBJ isn't a bad thought. Then we could just say "move left 1.5 pixels". I used xadd and yadd because in AstroStorm I started off the other way and found things quite jumpy when over 1 pixel. Some of these road "scanlines" need to move more than 1 pixel in a frame and it just seems smoother. I will admit, I didn't try just add/subtracting the x/y as you said though. I could track the line positions in an array, that way I would only need an RSET. Plus, if using the new function from ggn I could just POWARSET the whole array Will have to play around more.

Point taken, don't use the digits 6 and 4 in the title lmao Thank you also for the offer, I will let you know if I think of anything. Probably the only thing i've come up against so far that might help would be to be able to set the origin for scaling operations in the object file. Sometimes it definitely helps if the origin is the middle of the sprite rather than in a corner. This way I wouldn't have to work out the new x position after the object is scaled at runtime to keep it central (otherwise it scales out to the right etc). Cheers

Excellent! I will give it a spin, thank you. If I think of anything then I will definitely say, cheers.

Managed to test 1.2 on my PAL Jag tonight. I think I spotted the slowdown sh3 mentioned. Need to do some optimisation I guess :/ Also, I can see some wierd flickering particles at the top of the play area. They kind of flicker horizontally I think. Not quite sure what thats related to yet. If things are slowing down then it could be related but it didnt used to do that. Not sure if it has anything to do with the particle line issue from before either. I'll have to play around and see what effects it. Dangerous territory now though cause I've got this other prototype on my mind. Must focus!!! Get the last 10% done on this and then I can move on