Sporadic

oooooOOOOOoooooo yeeeaahhhhhh These look awesome, thanks to everyone involved.

I grabbed one. It seems good and solid. I had to clean the edge connector. It's also running the latest firmware. The only main concern to note is that it didn't have a beveled edge connector. It's completely square and just waiting to screw over the cart slot. So if anyone gets one of these, I recommend looking into how you file down the edge connector to more of a point like other carts. I've not tried this yet myself.

Pretty sure I tried that on Skunk and it didn't work. So possibly for now it's up to the coder to include the relevant snippet depending on target platform. I agree that it should be included in RB+, even if it's a build option.

I don't think anything was added. It might of course depend on a version, but it's not in the newer ones.

Hi, I just tested this on a real jaguar and there is something you need to change; The ROM width setting. At least for it to work on the Skunkboard. Open the rapapp.s file and look for this section (about half way down) ;; get something on the screen jsr RAPTOR_start_video ; start video processing move.l #LIST_display,d0 ; set RAPTOR to display initial RAPTOR list jsr RAPTOR_setlist ; tell RAPTOR which list to process jsr RAPTOR_UPDATE_ALL ; and update the object list with initial values jmp __Z9basicmainv if player=0 include "zero_audio.s" endif Paste in this code between those two sections; move.w MEMCON1,d0 bset #1,d0 bclr #2,d0 bset #3,d0 bset #4,d0 bclr #7,d0 move.w d0,MEMCON1 It should end up looking like this; ;; get something on the screen jsr RAPTOR_start_video ; start video processing move.l #LIST_display,d0 ; set RAPTOR to display initial RAPTOR list jsr RAPTOR_setlist ; tell RAPTOR which list to process jsr RAPTOR_UPDATE_ALL ; and update the object list with initial values move.w MEMCON1,d0 bset #1,d0 bclr #2,d0 bset #3,d0 bset #4,d0 bclr #7,d0 move.w d0,MEMCON1 jmp __Z9basicmainv if player=0 include "zero_audio.s" endif Make the above changes and post a new ROM and i'll test it again. This wont effect Virtual Jaguar from working. For more background info on this - see this post; http://atariage.com/forums/topic/256149-rom-asset-management-accessing-assets-from-rom-directly/?p=3575885

If you put anything into ROM, it will build a ROM file. The file will be sized according to the typical ROM sizes of 2,4,6 MB. You typically want it to be 2 or 4 MB, then it is most compatible. If you specify ABS for all your assets then providing it's less than 2MB (after build) you will get an ABS file. These are normally faster to load that a ROM and can be burnt to CD too. I cannot think of any reason your ROM would be faster than the ABS. I can't test it at the moment for you as I'm away from my computer but if I get chance tomorrow, I will. EDIT: Also, the 5 second delay is where it's decompressing the game from the ROM, so that is normal.

Atari2600lands snippet in this thread should work; http://atariage.com/forums/topic/266025-zooming-and-scaling-with-rb/?p=3771074

Paint shop pro is my go to for Jag stuff.

How tall is your destination sprite? Perhaps it's run out of space and you are poking values outside the bitmap.

The emulator is usually faster than real hardware. A quick win to save the slowdown and tearing would be to reduce the size of the particle layer. This is the transparent layer that the print commands and particles use. By default it is set to 320 by 240 px. You can make this smaller to reduce the amount of overdraw the downside being you can't show a full screen of text. If you look in the rapapp.s file - scroll down a little and look for raptor_particle_buffer_height . Change that to 16. This will give you about 1 lines worth of text area. Remember to change any rlocate statements to 0 on the y axis though. The print command itself isn't particularly fast either, so you could try commenting the frame counter out for now. If all else fails, you are probably best doing as CJ suggested and using 1 large background image, a 2d array for collisions and then just use sprites for special cases like crumbling blocks etc. Using lots of 16px wide sprites with an 8px image inside, when layed out next to each other, you are basically overlapping 50% of all the objects along every scanline. These are the kind of things that can crop up developing on old hardware Keep at it though, it's all part of the jaguar learning experience

Raptor does have built in animation and speed for frames. But if you need to roll your own then what i do is have a separate int and +1 whilst moving. Then only update your frames when that equals 3 (for example).

That's still the same isn't it?

Looking good

Instead of data, you could use Set varname[] As integer 0,0,0,0,0,0,0,0. Blah blah End set

Here's a link to a past post regarding this; http://atariage.com/forums/topic/243219-is-there-sprite-size-minimum-limit/?p=3332662

I have a feeling if i remember correctly, you cannot have a 4bit sprite only 8px wide. It might have to be 16 px minimum for 4 bit or 16bit and then 8px wide. One of the other guys will probably know for sure

Awesome. Can't wait to see your progress. Each object has a flip flag. So for example you can do rlist[objectnumber]. flip = R_is_flipped Or rlist[objectnumber]. flip = R_is_normal Where objectnumber is the number of the object from the object list that you want to flip. Also, this is a horizontal flip, there is no vertical. I think you can update almost all an objects properties this way. Hope that helps a bit. Typed on my phone so there could be errors. Also, in the RB+ folder there is a docs folder with a quick reference.txt and also a bcxbasic help file.

Instead of asking people if it's possible - just go and try it! It's the best way to learn. You'll find out 1 of 3 things; 1: The jag can't do it. 2: The Jag can do it. 3: If you play around with settings and try different things then it can do it. The upshot being, it either just works, you discover it doesn't work so you know limits for the future, you learn new ways to eek out more Jag POWA. It's not going to take you long to get that up and running and then you'll know one way or another. If it's just for goofing around then what have you got to loose?

Lets not get ahead of ourselves. Its a cube Having said that, i do want to keep playing around and see what's possible. It's not really using any lookup tables and everything is calculated in real time. I'm sure optimisations can be made. Thank you ggn for the help and new functions, appreciated as always. The good thing about doing something like this is that you learn new things and how stuff works. CyranoJ, if this was truly thrown together as you say then what a throw it was I couldn't be having more fun deving on the Jaguar. This depends how you look at it and where slowdown might occur. Yes it adds a bit of extra computation for each triangle but at the same time, it's drawing roughly half the amount of triangles it would otherwise be drawing, so there's less calculations done after the culling and less stuff being drawn to the screen. The net result should be that it's faster. Also, i'm using the result of the culling calculation to perform the lighting effect and no extra cost so it's being used for two things Thanks for the responses, if I make any other progress i'll post it here.

I just thought I would post a quick message on what I've been playing around with. Whenever I'm working on a big project (such as AstroStorm or Notoutrun) i always like to have a mini side project too as it serves as a nice break from the norm. This time i started tinkering with 3D in RB+. It's not much, just a cube but you gotta start somewhere. I started with wireframe; Then added backface culling, solid triangles and basic lighting. There is a known issue: A rounding error exists which means after a while the cube shrinks. I know where it's happening i just haven't looked into correcting it. Binaries attached too. SporadicSoft 3D Cube in RB+ 040317.abs SporadicSoft 3D Cube Solid in RB+ 130317.abs

Sounds great so far. Well explained

Definitely if you know a version of basic then it will help you learn another. There are always platform specific details to learn though and even the way of doing particular things. Eg. in Raptor / Rb+ you have to learn about the assets and object list in order to display graphics. Then there are the functions to call to play sounds. Things like that. But the main flow and structure and even commands you use from basic will be the same or similar.

I hear you, I'm not intending for everything to be like that or necessarily that extreme or for rocks to do those things.... Those were examples of what it can do. Also, you don't know the back story of the game

Yes, i'm enjoying applying what i've learnt in other demo projects back in to things like this.

I've been playing around with some other movement patterns for the rocks. Here's a video where I've assigned different styles to each rock as a bit of an example. If you watch it for a bit, you should be able to see what each one is doing.