vidak

Well I sure learned something here. This is amazing help, in my opinion.

I think the easiest way games would display all colours is just storing a decremented or incremented value in COLUPF or COLUBK. That way you can get 128 colours up and down the screen like in Kirk Israel's beginning Beginners 101 tutorials. Pretty much the same thing as what SpiceWare pointed out.

I saw this on facebook! Super interesting device. From my 3 seconds looking at the image, it doesn't seem like there is a lot of electronics in the actual device. Atari joysticks are just arrays of switches, so it seems like this device might just test the conductivity of the switches. But then again there are some heatsinks on either side of the board... so I'm not sure if it has any active components...

I had a lot of trouble getting my mate's Master System to work properly when its RF output was plugged directly into a new LCD TV - the changing number of scanlines on the title screen and in different sections of the game caused the TV to display fuzzy black and white images. So I think a VCR is actually a pretty smart way to swing your setup - its the cheapest option, and it gives you the most bang for your buck. I'm with everyone else here - if you're happy with it, then it's all good!

The way I imagine it is that the TIA will draw your sprite at whatever position on the screen horizontally you set. So when you write to RESPxx and then HMOVE, the TIA is automatically waiting for you to draw your sprite VERTICALLY, and will basically draw your sprite at the correct horizontal position as if by magic. So it's actually false to say the 2600 is hard to program, because it actually does a lot of important stuff automatically!

I've kind of stalled on finishing this, but I have completed most of a new dig of the Stella Mailing List from back in the 90s and 00s. It's here at http://bootlicker.party/commo-dig Personally, I think it is too difficult for new non-programmer fans to start developing games in ASM. There is not a unified location on Atariage for people to logically develop every known skill for 2600 development. I have mastered as much as a beginner can through sheer force of will and determination. I think most people should not have to try this hard. Kirk Israel's 101 guide is amazing, though. It is everything a complete rookie needs. We need a hundred more guides like that. I am willing to give say 8 hours a week contributing towards a more comprehensive guide for beginners. Some things on only became clear to me after looking at 8bitworkshop.com. I am not against using something like that to do a codeacademy.com for Atari games. I am so, so grateful for Stella, Collect, StayFrosty and so on.

Yo! One of my friends who runs a radio show in my home state of Western Australia interviewed me statewide about the 2600 homebrew development scene! Needless to say, I had nothing but positive things to say about how we're all working towards making amazing games for the 2600! I directed everyone listening to come to AtariAge.com! Please find the MP3 of my interview attached. I have also uploaded the interview to SoundCloud! https://soundcloud.com/blair-vidakovich/blair-vidakovich-rtr-fm-interview-about-atari-2600-homebrew-games Blair Western Australia Radio Show.mp3

Happy New Year!!

Merry Christmas! I love reading your blog.

Well, happy new year. 2017 was a real bastard of a year, but I'm ready to get stuck into 2018. Time to get back into coding the Guerrilla Game!

Just a little advice regarding netiquette - always treat a response on a forum as if the user could easily have not bothered. Manners always help. I'm starting to get my head around the 2600 so I'm always here to help with debugging. If you're starting from scratch, like I was, if you work every day on coding you will become a medium skilled beginner like me in 6 months. This is going to take a lot of effort, but we're all here to help!

I can put some time and effort into this!

This is amazing. I am learning so much from hanging around on these forums. Happy New Year everyone.

Ah okay. I agree. That is the problem. Anyway, I'm back from my enforced relaxation now, and I am going to attempt a new rewrite of the kernel using the masking method, which is undeniably faster. Again, thank you for all your help

The lock and load section of the game is kind of a small strategy game. You can move, block, load, or shoot. The idea is to chase down your opponent soldier and shoot them. If they block in the same turn as you shoot, they avoid any damage. I will be drawing a beach background, a jungle background, and a mountain background.

I don't think it's true that I'm only executing one code path or the other - I am executing both code paths when GRP0 and GRP1 are both drawn in the same band. I will get back to you about the lock and load section! My short answer is that I will only be drawing the middle 32 pixels - I'd like to have as high a resolution as possible. I am hoping to have at most three different backgrounds. One for the beach, one for the jungle, and another for the mountains. This part of the game will not have bands of soldiers. It will only have 2 multicolored sprites on the screen. I will also use 8x width effects to create different objects.

Ah okay. Is there still enough time in the kernel, though? That's mainly what I was worried about...

Just in response to ZackAttack - the graphics code for GRP0 needs to be skipped until the correct Y position for Player0 is reached. If I remove that branch, then Player0 will be drawn at the earliest possible opportunity. That branch is a part of the FlipDraw routine. I think this kernel will not work in the long run. I think I have three options: 1. Use SpiceWare's masking technique 2. Use some version of VDELxx in a 2 Line Kernel in order to try and get single line resolution Option 2 would be considerably more difficult than Option 1. There could be an option 3: 3. Use DoDraw for GRP1, and use FlipDraw for GRP0. This is just an idea, it will almost certainly not work because it will take too long. It would require decrementing the scanline counter in memory and reloading it into Y every time. Overall my current kernel is too slow to draw 2 multi-coloured sprites. 8bitworkshop.com seems to be able to achieve 2 multicoloured sprites AND a playfield, so I will study that code and see what I can learn. 8bitworkshop uses VDELP0, so I think this may be the way forward.

Thanks for both of your help! I think I can fix this now!

I'm a little stuck again. I implemented the STA HMCLR like people suggested, and that fixed the erratic horizontal movement problems. However I now have an issue with the kernel, and the graphics pointers. In order to save time in the kernel, I store Player0's graphics to the Y register at the bottom of the kernel. HOWEVER, the GRP1 calculation routine is starting too early, and is causing the index of the GRP1 graphics to be loaded into the Y register, which is what is causing the black band of artefacts in each band of the screen where GRP0 doesn't appear. Could someone explain to me how my pointers and Y offset variables are working? I can't seem to understand how to line up the (a) Y offset; and (b) graphics pointer. I think I am also running out of time in my kernel... Anyway, if anyone could have a look, I'd be very grateful : ) guerrilla020_bin_files.zip coloured_guerrilla020.asm

You can check out my (nearly complete) annotation of the Stella Mailing List here: http://bootlicker.party/commo-dig

This forum is amazing, I really mean it.

Thanks man : ) I really have to thank you all for helping me. I really love this community : )

I thought SpiceWare was saying I should do exactly what your crossed-out text said - what is SpiceWare suggesting if not that?

Oh!!! I could just write HMCLR before I position GRP1!!