Any sprite rendering algorithms you know of?

[DementedPurple]

One of my big questions I have is how I would have an algorithm to figure out where it is on the scanline and then know how many scanlines it has written. I would have to do an increment after every single instruction, and that would waste many precious CPU cycles and ROM space. I guess I could have a register for the X-Position, one for the Y-Position, and one for where in the Scanline, and one for how many scanlines it's written. But wait, I will not only not have enough registers to use them for anything other then that, but I'll also be using more registers then there are inside the CPU.

[+SpiceWare]

Seen my tutorial? It's in the blogs so entries are listed newest first. As such, go to the bottom of the last page to start.

[ZylonBane]

No no, he's obviously right, sprite positioning on the 2600 is impossible.

[DementedPurple]

No no, he's obviously right, sprite positioning on the 2600 is impossible.

Well, it's certainly possible, it's been done in every single Atari 2600 game ever released.

[+SpiceWare]

I added an index to make it easier to follow the tutorial.

[DementedPurple]

I added an index to make it easier to follow the tutorial.

Yeah, speaking of your tutorial, it's not really a tutorial as in it actually teaches you stuff about programming the Atari as much as it is just a bunch of code without anything telling you what any of it actually does. I don't mean to be rude, but I came from this tutorial here: http://www.randomterrain.com/atari-2600-memories-tutorial-andrew-davie-21.html I found this tutorial helpful and so if you don't mind, could you try explaining it in a way similar to what is used in this?

[+SpiceWare]

just a bunch of code without anything telling you what any of it actually does.

Really? The green text in these screenshots are all comments telling you what the code does...

 

 

I don't mean to be rude

you failed, miserably

 

if you don't mind, could you try explaining it in a way similar to what is used in this?

I do mind as it's obvious you haven't really looked at the tutorial.

[DementedPurple]

I'm sorry I came across as rude, I just can't find which section has to do with sprites, and I simply don't want to have to read the tutorial in it's entirety just to get one bit of information. Imagine if you wanted to find a word in the dictionary, but in order to find it, you had to read everything that came before that word, that would be annoying. The point is, I just need one answer for one question, and I just simply don't have the time to read your entire tutorial.

[ZylonBane]

I would bet you've already wasted more time whining about not being handed the answer to your question on a golden platter than it would have taken you to just plow through the tutorial like a normal non-entitled brat. God forbid, you might have learned some other useful things too.

[Mr SQL]

Why attack the OP? Andrew Davie's Assembly lessons are easier for a beginner to read and very clear.

 

DementedPurple,

Andrew Davie's sprite tutorial has most of what you need to know; you will just have to set the horizontal position registers. Everyone uses the BattleZone positioning routine to perform that function because it's the most efficient.

 

 

[Kiwi]

One of my big questions I have is how I would have an algorithm to figure out where it is on the scanline and then know how many scanlines it has written. I would have to do an increment after every single instruction, and that would waste many precious CPU cycles and ROM space. I guess I could have a register for the X-Position, one for the Y-Position, and one for where in the Scanline, and one for how many scanlines it's written. But wait, I will not only not have enough registers to use them for anything other then that, but I'll also be using more registers then there are inside the CPU.

You do have 128 bytes of RAM to keep track of x and y position. From Andrew Davie tutorials in the programming forums, if I recall used the y register to increase the register. x I believe used as a dec to graphic graphic data from a pointer. a register if you need to do calculation during the rendering process, can't inc or dec a register since that chip didn't have that feature. You can inc and dec RAM address though. If you are serious about Atari 2600 programming, I would highly suggest to go through the tutorials. X reposition uses HMOVE, which how there's more than one objects on screen using the 1 sprite. There are features for the sprites that resize them or clone them, which give you more objects to work with.

[+SpiceWare]

I just can't find which section has to do with sprites, and I simply don't want to have to read the tutorial in it's entirety just to get one bit of information.

First thing to do is to get your terminology right. On the 2600 the moveable objects are called players, missiles, and ball - not sprites (though on occasion, due to modern usage, you'll see sprite used when referencing the player object). They have different names because each object type has different attributes - pages 22-24 of the Stella Programmer's Guide covers that in detail. Step 1 of the tutorial tells you where to find the guide.

 

Not knowing the correct names would make it difficult to skim the tutorial to find that positioning of the players is covered in steps 4 & 5. However, you do need at least the framework in place from steps 1 & 2 in order to even render a screen on the 2600. 1 & 2 are both very short, so it won't take long to read the blog entries and look at their associated source code. Step 3 goes over how to display numeric values onscreen for the score. You can skip that if you like, though I find it extremely handy for debugging problems with code as you can use them to display values other than a score. You can see an example of that in reply 141 and 145 where I helped atari2600land figure out why the paddle routine started to misbehave in his game.

[+SpiceWare]

On my lunch break I've made some updates to the index that should make it easier to find things. I'll make additional revisions later this week.

[+thegoldenband]

Happened to notice a thread on NesDev that helps to clarify where the OP is coming from:

 

https://forums.nesdev.com/viewtopic.php?f=5&t=15946

 

If it's true that he's 12 years old and has autism, it might suggest a different approach. (Or not, YMMV.)

[Mr SQL]

Happened to notice a thread on NesDev that helps to clarify where the OP is coming from:

 

https://forums.nesdev.com/viewtopic.php?f=5&t=15946

 

If it's true that he's 12 years old and has autism, it might suggest a different approach. (Or not, YMMV.)

 

Just read that thread - I think that Atari 2600 Assembly programming can have an even easier approach than Andrew Davie provides for beginner programmers by abstracting the hardware.

 

DementedPurple,

here is a link to the ASDK, it let's you program the 2600 in Assembly more easily by abstracting the hardware to look like the NES:

http://atariage.com/forums/topic/203463-abstract-assembly-development-kit/

 

Programming in BASIC is a lot more fun than Assembly and you can also use Flashback BASIC (linked below) to create Atari 2600 games with large virtual worlds like the NES.

[tokumaru]

Programming in BASIC is a lot more fun than Assembly

Objection! I find the kernel design part really fun, where we have to think of crazy ways to cram as many features as possible per scanline.

[+SpiceWare]

Objection! I find the kernel design part really fun, where we have to think of crazy ways to cram as many features as possible per scanline.

 

 

The challenge of designing the kernel is why I develop for the 2600, there's nothing like it on other systems.

[Thomas Jentzsch]

The challenge of designing the kernel is why I develop for the 2600, there's nothing like it on other systems.

/signed

[tschak909]

 

 

The challenge of designing the kernel is why I develop for the 2600, there's nothing like it on other systems.

/signed

[tokumaru]

Kernel design truly is what sets Atari 2600 development apart from everything else. And it's not just the fun of making the features fit, but each game ends up looking very distinct due to having a unique kernel, which is a gratifying feeling for the developer.

[Mr SQL]

Objection! I find the kernel design part really fun, where we have to think of crazy ways to cram as many features as possible per scanline.

 

Agree kernel design is fun too, NES programmers use the PPU chip and Atari 5200/400/800 programmers use ANTIC even when writing their own kernels so pure kernel design is largely the domain of Atari 2600 programming.

 

But it's tremendous fun to program Video Games in BASIC and I think writing a game in a few pages rather than hundreds allows for a more creative process.

 

I think you would like the pure kernel aspect of the project I am working on to create a 5200/400 soft blitter chip using just CTIA:

 

http://atariage.com/forums/topic/264913-display-lists-for-fun-unlimited-horizontal-scroll/?p=3753891