sh3-rg

If you're really stuck and bored, check the object definitions for duplicated lines, I had a couple of similarly weird issues when I'd done some shoddy cut'n'paste action.

hot tips: listen to sporadic & ggn look here: http://www.extentofthejam.com/pseudo/

IIRC, when you're sending stuff off screen to not be displayed, it's best to use y as it'll be culled from the object list. If you use x, it'll still factor into calculations each life buffer pass it is present on in y. Also, think there's a danger it will reappear back on the other side of the screen.

Nice work! Keep at it, when you get deeper into rb+ you'll find it's insanely powerful and incredibly addictive. I mean, asking if you can display two 64x64 sprites at once is sooo cute, hold on to your hat you're in for a wild ride

You can't open those up, nope :/

All that does is save you from typing out all the exact same info a 2nd time (or copy/pasting it) and allows you to make changes to all objects of that type with one edit. If your ant is the first object in the list, the copy of it would be the 2nd object. So whatever you do to make the first one move, you'd do the same but wherever you access object one, you'd need to access object 2.

What kind of magic do they use then? They need all 256 colours of the colour look up table (i.e. all rb+'s 16 sets of 16 "minicluts")... or rather, they can make use of all 256 colours in the CLUT. EDIT: So your solution could be to use 16bpp for your animation (wasteful) or rework the graphic to something like 48 or 64 colours, it'd keep most of the quality (the graphic could do with touching up anyway, the halo like it's been clipped off a bright background is a bit nasty/amateur-looking) but you'd just need to manage the clut properly/reserve the 3 or 4 minicluts for this graphic. It's usually user error. Not always, but 99 times out of 100 yep, you're doing it wrong. Not you specifically, just 99 out of 100 people who report errors and insist they're doing everything right and the world is broken.

It is for the "text layer" or "particle buffer layer" - GGN is assuming you're using this 4-bit object for your background platforms/level layout. If you're not you simply have to grab the address of the source gfx data (that pointed to by your backdrop object) and adjust your calculations when peeking to suit bitdepth. If you wish to think of it that way and it helps, sure. The display on screen is produced a line at a time effectively as a collage, or rather a series of thin collage slices. As I said above, design your game using the features that raptor makes easy for you and everything becomes easier. You can use CD 1 vs 1, 1 vs many, many vs many. It's very simple, clean and efficient as the GPU takes care of it for you. Consider how the screen is produced. For every line of the display, the OL is traversed and the image built up for all objects that appear in that line*. Ideally you will want to limit this number where possible. Object height obviously impacts as well as a taller object will appear in more lines. Your plan to have a single background image for the whole level layout obviously saves heaps of bandwidth here but with the added complexity of hand-coded CD. IMO, when it comes to a game like Manic Miner, people might expect pixel-perfect collision detection if they're used to experiencing that in previous games. Bounding box might either feel a bit unfair or too cheap when the player sprite animates and phantom collisions are seen or toes poke through platforms etc. *You can use branch objects for OL efficiencies, but that's something you might only want to bother with towards the end of a project if there's a fine line between a locked framerate or the OP shitting the bed. EDIT: If I were making a game of this type, I'd definitely stick with doing everything object-based. Clearly having a screen full of speccy-like 8x8 objects would be unrealistic - the OP would go into meltdown. But with some clever object design, use of much more chunky, larger but still reusable lumps of platform, there would be a happy compromise between simplicity of coding, object count and level design. Pixel-perfect collision detection would still be a challenge and it might be that I'd have to have to adjust the hitbox per frame to suit the gfx (but more sensibly, just design the graphics and animation in a way that bounding box works well).

rb+ has some really nice routines for object vs object collision detection, using raptor's gpu routines nice and speedy. Obvs you can't use those if you generate your backdrops (platforms) as a single object using map data (guessing that's what you're doing as I can't remember and can't be bothered reading back through Ignore the rest of this if not, hah). So you'd maybe want to peek at the backdrop object data at offsets from the current player sprite object coords, maybe just a handful of sensible ones rather than a whole solid block and have different patterns based on the gfx appearance in the frame? You could do it less efficiently and less hardcoded by simply peeking at the backdrop object data at an offset from the player object position for every pixel in the player sprite that is non-zero, iterate through all those every frame, it'd certainly help with edge cases where background gfx have black holes in them. It's definitely simpler making games with rb+ when you make the most of its features and hand-holding, designing a game within the confines of what rb+ makes easy/trivial rather than having to get messy

paint shop pro 8 is one of the best gfx editors for palette-based stuff.

shootbang project demonstrates player, enemies, bullets, collisions and explosions.

Damn fredi, you couldn't just wait another 6 months and have a decade old bump?

I had some clicky problems when looping ulaw samples, I fiddled with the end position and it vanished. Never mentioned this to anyone, probs should have.

To keep things simple and tidy I use separate BAND statements and stack them up as needed. So looking for button press and right... IF (LVAR_pad BAND PAD_A AND LVAR_pad BAND PAD_RIGHT) THEN

A couple of times I think I imported a 16bit asset and used it as a colour palette, peek at it and poke into colour register, to save xunting around with RBG values and shifting around, just draw your palette in PSP or whatever.

You can use 16bit objects and not worry about colour palettes as I think you are suggesting, but you can also use lower bit depth objects that use the whole (8bit image, 256 colours) or a specific part of (1,2,4bit, 2, 4 or 16 colours) the CLUT if you want to save memory and bandwidth, both of which are usually at a premium. Within the context of rb+, you can think of the CLUT as one large 256 colour palette* or 16 smaller palettes, you can think of these as "mini CLUTS" if it helps (I do). So with your two images that you wish to use as objects, you would have to design both the 256 colour object and the 16 colour object in a way that the one did not impact on the other. Now you could either reserve 16 of the 256 colours and use, say, the first 240 colours for your 8-bit image and have a unique 16 colours for the 4-bit object. Or you could use all 256 colours in your 8-bit object and carefully design the palette so that it had 16 useful colours for your 4-bit object within one of the 16 chunks of 16 colours. Here's an image that hopefully demonstrates this better than my crappy words: So in the above examples, you can see the whole CLUT is set up with the first 15 sets of 16 colours being a rather boring gradient and the last 16 of 16 a rainbow of stark colours. The first object is 8bit, it can use any of the colours in the whole 256 range of the CLUT, but it only uses 0-239 as it's not needing those garish colours at the end. The 2nd object is a 4bit (16 colour) one and is designated to use the last 16 colours (mini CLUT 15 in the range 0-15) as its source for colours. The 3rd object is exactly the same as the 1st one, but also uses the remaining 16 colours for some lovely embellishments! There are also examples of 2-bit and 1-bit objects. These use the first 4 or 2 colours of each mini CLUT. With the above, you should also be able to see how you can drastically change the appearance of an object simply by assigning it a new mini CLUT value. * (it's rare you'd want to, efficiencies over 16bit are... limited? Although Bexagon makes good use of it for example as it hammers all the colour registers every frame)

It's not fixed, but maybe it's an idea to work within the range 320x200 and 352x240ish. Some TVs overscan a little and different standards (PAL/NTSC) will also be set up to show different sized screens. Those are the kinds of ranges I work with.

Amazing stuff, Rik, looking forward to seeing more goodies like this, your side projects are my favourites

I gave up using binary for scaled objects because it was too easy for my stupid builder fingers to arse it up and my old man eyes found it difficult to spot the mistakes, so used integers instead and had a very happy, successful and fruitful life ever since.

10 PRINT "Everything GGN says is true and Geminitronic is correct in saying you'll have to think about things differently when it comes to how Raptor leverages the Object Processor and how the Jaguar produces an image on your screen"; 20 GOTO 10 In fact, there's a pretty clever little getaround with rb+ that allows you to do some of the primitive BASIC stuff such as PRINTing text and PLOTing pixels. But as soon as you're up to speed with Raptor's object handling fun, you ain't going to want to fanny around with any of that anymore! So if it's Jaguar things you want to make, I still say get a feel for how the Jaguar does things and how Raptor exposes lots of the fun to you (in fact, without even having to write a single line of code or have any sort of understanding of programming concepts, just text-editing existing files! ). You can absolutely jump in to rb+ with zero programming experience if you are patient and are willing to learn, not just want someone or some text book to dump it in your lap.

Agree with the above. If it's Jaguar you want to target, jump in to rb+ and begin learning about the weird and wonderful Jaguar as you go. Everything you learn will be 100% helpful and useful, whereas learning all that line number atari basic and hardware-specific features stuff, it's wasted effort and might even make things seem more alien when you do get around to rb+. You might be surprised just how much you can do with just a few commands thanks to Raptor, but a little background of the included tutorials, particularly tutorial 0, is essential before you begin fiddling. that's where I'd say spend your time - learn about the Jaguar, the Object Processor and Raptor, not Atari Basic. If more people do this from scratch, experience and feedback will help make it easier for the next people trying their hand. If more people do this from scratch, experience and feedback will help make it easier for the next people trying their hand.

I'll be more specific. Doger is a tutorial. It's there to help people get a leg up, a super-simple project that puts the basics of rb+ in the context of a simple working project. The idea is to read through all the tutorials and view Doger as a simple demonstration of the things you read about previously, then maybe use it to play around with things, chop it up, change things around, see how your alterations affect the game as it is played - a bit of a simple sandbox project to fanny around in. What Doger isn't is a project to cut & paste without understanding any of it, swap the assets out of and claim it as your own game. If you had worked through the tutorials and gained even a very basic understanding of what the simple routines in Doger actually do, your issue would stand out like a sore thumb and there would be no time wasted making youtube videos and making posts, you'd be on with making "your" game. I find it quite sad and somewhat disheartening to see you here asking such questions, posting the project including .BAS file that demonstrates that I was correct in thinking that you'd done nothing much to the code other than managing to break collision detection and introduced other issues... and now you're back here wanting people to write the game for you. Well that's just not in the spirit of things, is it? You've now sold 8 copies of "your" game on eBay at $20 each. I have a solution. Cancel that listing. Promise to not be a dick anymore and not sell other people's work as your own. Take that $160 and donate it to the ACLU. Post the receipt here. A short while after you do all that, I'll post the fixes to "your" game and you'll be able to have 2 frogz running around the screen.