Sporadic

I put this request in the thread for my new game in progress but the formatting got mashed so it might have been missed. Easier for other people to find anyway if posting separately. I am after some help with smooth sprite scaling if possible. I played around but could only get it to scale with whole numbers. I couldnt work out the correct sequence or bit shifts to pass to setobj for the scale size. It has been mentioned in the tutorials for sprite positioning but I just had no luck with it. Eg. If I have a float variable for the distance to the screen then I'd like to translate that to a scale size at runtime. Then perhaps I could have missiles coming at the player , into the screen. So a missile might be a 32x32 sprite and start scaled at size 1. Then I would have a float variable that would gradually increase each frame by 0.25 for example. This needs "translating" to the sprite scale setobj command and set each frame. Thanks in advance for an help

Excellent, I like it! They would be pretty cool to add. I had thought of some kind of start level where you navigate to a planet. Depending on what you do it sets the seed for the random level. Maybe that could be an adventure mode hehe. Cheers for the input. The .bas file is getting monolithic already lol Its going to be huge after more additions.

@CJ Cheers. Yes that sprite sizing makes sense. I found I had issues with other sizes too unless they were divisible by 8 if I recall. Even big sizes. Memory track would be awesome but no rush, please do in your own time. Is it pure Memory track or does it support cart/skunk saves too? If the skunk can save that is, not owning one, I've not looked into it. @ggn Yep those are cool ideas. I'll put some thought into that. I've shot myself in the foot really because you dont control a player character, there is nothing for the bad guys to shoot at. They would have to shoot into the screen. I had thought when a bad guy appears then the sheild could reduce quicker. Not as fun as getting shot at though. Could also add something in the viewport you have to protect. Mouse idea is cool, but I'm kind of a purist. I wouldnt want to alienate anyone from playing. Also, they would have an advantage and get higher scores. I think I'd rather force people to use the jagpad muhahahahaa. (I actually like the pad). So don't worry about digging that out. Although might be interesting im the future. I am after some help on scaling if someone can help out. I thought it might make it more "Jaggy" with some scaling sprites lol. Im having trouble doing smooth scaling. I could only get it to scale with whole numbers. I couldnt work out the correct sequence or bit shifts to pass to setobj for the size. Eg. If I have a float variable for the distance to the screen then I'd like to translate that to a scale size at runtime. Then perhaps I could have missiles coming at the player , into the screen.

Thanks for the kind words. Glad you enjoyed it! Yes, once I got to grips with some things it went much better. For example, to start with I was moving the crosshairs manually 3 pixels at a time. I also used a vsync in the main loop. This was ok on the emulator but once on the real Jag it was pretty slow and jerky. I changed the crosshair movement so that when dpad direction is pressed it sets the R_sprite_xadd or yadd to 3. Then at the start of the next main loop, reset that back to 0 ready for next input. This allows RB+ to do the smooth sub pixel stuff I also removed the vsync and changed to the Rupdall(1) command. That is lots faster than a manual vsync call! The starfield is real time, 16 sprites used for that. Its randomly created on start and then when the stars vanish they are reset to their original positions. Its hard to spot and saves generating random numbers at runtime. I'm thinking what to add next, would be nice to have some level variation or gameplay variation and push the Jag more. I was pretty surprised how easy it handles the full screen 16bit graphics. I stopped using the 4bit stuff and ended up doing most things 16 bit. It doesn't seem to slow things down. Perhaps it would with more going on? Some things like the rocks and stars are 4bit. I also couldnt seem to create any sprites smaller than 16x16. Anyway, I'm rambling now. Its just nice to talk about it and brain dump. I'm open for suggestions if any come to mind. Memory track saves would be nice ..... If I'm remembering correctly that Raptor supports them. Hint hint Cheers again guys.

Thanks! Couldn't have done it without you guys.

Hi all, I'm currently working on a new game using RB+. Been finding it really cool, once you get used to the way to do things. I put the Light Cycles project that I mentioned elsewhere on hold for now. It's a simple shooter where you blast away all the rocks before your shield runs out The shield will wear out quicker as the levels get higher. I'm thinking about adding some baddies to shoot back at you, different size rocks, etc, it's still WIP. All levels are randomly generated based off the same seed, so everyone should get the same levels every time. It just means I can be lazy and don't need to design waves for each level. There are 3 types of rocks, each gives a different score. Apart from looks and score, they aren't any harder to kill or anything yet. Still thinking that over too. You score will increase as you shoot rocks but at the end of the level your score is reduced based on time taken and shots missed. So don't just hold down the fire button if you want a big score. If you press Pause on the controller (once playing) then you can pick 3 sound detail levels: 0 = Mute, 1 = All sounds except player shooting, 2 = All Sounds. For some reason, sound level 2 blows up Virtual Jaguar randomly and crashes. It seems ok on my actual Jaguar though. I've tried a few things but not fixed that yet (could be cause i'm spamming the SNDPLAY too frequently?). So if you use an emulator, it's probably best to use sound level 0 or 1 for now. The game defaults to lvl 1. Also in the emulator, some sounds just randomly don't play. Again, this seems ok on my actual Jag. Please have a play and try out the ABS. I've stayed away from using a ROM because I want to play it on my Jag and only have a CD drive to play homebrews. No method to upload ROMS. I've attached some screenshots and an ABS/ROM for your convenience. I might post a video at some point. Also, if I tweak anything, make changes etc then i'll post new versions here. Controls B = Fire D-PAD = Move crosshair PAUSE = PAUSE (yep!) / Unpause *+# = Chew on a grenade When Paused, 0,1,2 to change sound detail Happy shooting. AstroStorm.abs AstroStorm.rom

Hi, I know this post is old but I just had the exact problems talked about in this thread. Mine also had a weird random blob of solder on the contacts! Also, if using option to view the contents of the memory track, the saved names would show jumbled characters too. I thought it would be useful to post a photo of the rogue solder in case someone else has this issue. Perhaps it was a faulty batch? After just picking it off with my nail, the memory track works perfect. Didn't require heating with a soldering iron or anything.

Hi, yeah I am setting the basic vars and not using rupdall. That's fine, I am more than happy to leave it as is. If a big problem arises then I will provide source etc. I would rather move on and build up the game more and only revisit this if needed. Cheers for your time, Rik

I just had a play around and have managed to stop the crash. In the sub shown below, I ended up having to add the 2 vsync calls to fix it. Once after the CLS and once between the while loops. The first while loop draws the top and bottom walls and the second while loop draws the left and right walls. This sub never crashed when first used, only after game over and pressing a joypad button to start again. Could it be that something was overflowing with all the plot calls within the while loops and now, calling the vsync twice is flushing it out? I've no idea how anything works in the background so just giving my impression. SUB setupwalls ax = ax1 ay = ay1 CLS vsync COLOUR(wallcolour) WHILE ax < ax2 PLOT(ax,ay1) PLOT(ax,ay2) ax+=1 WEND vsync WHILE ay < ay2 PLOT(ax1,ay) PLOT(ax2,ay) ay+=1 WEND RLOCATE 120,0 print "LaserBikes" END SUB

Yeah i would love to get some funky graphical effects in there. I guess I'll keep playing around and see what happens. To start with i have just been getting the main mechanics done and getting familiar with it all. I'll check your suggestion about the crash, it sounds like a good place to start. cheers

That did it. Nice solid lines now Thanks again. If I get anywhere with a game then i'll be sure to post results etc. There is something else I have noticed but I cant give enough detail at present. If I can at some point i'll try post an example in the bugs thread. Basic details though, the game runs fine, but sometimes (depending on how much plotting i've done) the emulator shows a scrambled screen and closes down. I don't know if i'm just overloading something, no idea. Don't worry about it for now because it could be that I messed up elsewhere and it's not a bug at all. As I said, if I can produce an example .bas file to replicate the error then i'll post in the bugs thread. cheers, Rik

Excellent, thank you ggn! That function is perfect, exactly what I was looking for. I added in the code as described and it worked straight away. I then had a thought, I had some code from when I was messing around for getting the memory address and tried it out - that seems to work too. This means I don't have to modify the rbasic.h source code; First I grabbed the address from the particle layer asset; DIM mem% mem%=RGETOBJ(0,R_sprite_gfxbase) Then modified your code as below, just plugging in the mem% variable; function getpixel(x as short, y as short) as short if x band 1 then function=(peek(mem%+x/2+y*160)) band 15 else function=((peek(mem%+x/2+y*160))>>4) band 15 endif end function I'm just playing around to try out stuff, using the GetPixel as collision detection. I know this could be done other ways with an array etc but thought it might be cleaner to just check the pixel colour directly. It's not exactly a hardware taxing game Here's a picture of what i've created so far to make it clear what it's for (pic hosted elsewhere). Red line around the edge is a wall, orange line is player 1. As a side note, not sure if this is a bug, I can log in the other thread if you like - but it seems to be plotting a black pixel directly to the left of the actual pixel I am plotting. This can be seen in the above picture by the horizontal lines that have been drawn left to right. I wondered what it was at first thinking I must have been adding 2 to the x coord but that's not the case. As i'm using the getpixel for collision, it means that if you're lucky you can zoom through the dotted line if you happen to line up with a black pixel or when travelling right to left you just go through yourself because the pixel in front of the "bike" is always black. Anyway, thanks again for your work. It's been fun messing around so far. I have also added a second player to above game and would like to keep fleshing it out. Rik.

Hi all, First post here so first of all I wanted to say hello! I've been having a play around with Raptor Basic+ and it looks promising. Very nice idea and a good way to get people into some Jaguar programming. The tutorials were straight forward to follow and i've had sprites on the screen etc. I have recently been messing around with the PLOT function as a way of drawing pixels to the screen. What i'd like to know is if there is a way to get the colour of a pixel from the screen (where the PLOT has drawn to) using x,y coords? I had a play around with the PEEK commands, thinking that I could get it that way by using the address of the sprite_gfxbase of the particle layer. I had some limited success but couldn't really get it to do what I would expect. When it comes down to it, I don't really have the knowledge in that area. Any help would be great and thanks for reading. cheers, Rik