vidak

oh you're totally right! that'll totally increase the parsimony of the programming

Okay. I've completely solved the issue. Che will now animate and walk around the screen (a) with the proper limits; (b) at a delay of 10 screen frames per animation frame. Please find the source code, symbol files, and binary attached. This was the problem: AnimateHorizontalYes: inc AnimateHor0 AnimateHorizontalNo: lda AnimateHor0 and #2 sta AnimateHor0 sta Animation0 jmp SaveFrame The AND operation is a bitmask operation. It will only let this value through: %00000010. Because we are counting up from 0 to 2, it masks and returns a value of 0 every time. So we are never allowed to count up to 2. This means Che will never animate horizontally. This is what I replaced the code with: AnimateHorizontalYes: inc AnimateHor0 AnimateHorizontalNo: lda AnimateHor0 cmp #2 beq .CntHorCntr bcc .CntHorCntr bcs .ResHorCntr .ResHorCntr lda #0 .CntHorCntr sta AnimateHor0 sta Animation0 jmp SaveFrame It's slower, and more ugly, but it works. Now my goal of getting Che to walk around the screen has been completed. This marks the end of the first phase of the development of this game. There may be 20 or 50 phases of development, but this is a huge step for me. One thing I need to do right now is fix the colours on the graphics to make sure they all match. coloured_guerrilla010.asm guerrilla10.bin guerrilla10.lst guerrilla10.sym.zip

I DID NOT KNOW THAT. WOW!!!! I know that may be an over-reaction but that actually makes my life so much easier!!

I have managed to get the Che character to animate properly while he is moving up and down. This is how I solved the problem. The order of operations in the AnimationDelay subroutine used to be this: AnimationDelay: inc AnimFrameCounter lda AnimFrameCounter cmp #9 bcs .ResFrmCntr bcc .IncFrameNo beq .IncFrameYes ... rts Now BCS actually branches if A is GREATER THAN OR EQUAL TO the value in memory. This was causing the local frame counter to constantly be set to zero over and over again. I think THIS is the proper order in which you should test if a number is equal to a certain number, or if it has gotten too high for the loop: beq .IncFrameYes bcc .IncFrameNo bcs .ResFrmCntr Changing the order of testing to this caused the animation sequence for Che moving up and down the screen to work. guerrilla8_6.bin coloured_guerrilla009.asm

Okay! That gives me some ideas. I have made some progress in the meantime. I will put my improvements here just in case they help someone. I have a counter for each direction of animation. What is meant to happen is when you move the joystick, the frame delay counter increments every frame. When the frame counter reaches 9 (0-9, so ten increments), it will increment the frame of animation that is meant to be displayed. The frame of animation is then stored into a global animation index, which then points to the animation frame in ROM. However I was not saving that global animation index properly: AnimateUpYes: inc AnimateUp0 AnimateUpNo: lda AnimateUp0 and #3 sta AnimateUp0 sta Animation0 clc adc #7 jmp SaveFrame This is how the code is fixed: AnimateUpYes: inc AnimateUp0 AnimateUpNo: lda AnimateUp0 and #3 sta AnimateUp0 clc adc #7 sta Animation0 jmp SaveFrame The second big mistake I made was calling a subroutine like this: bne AnimationDelay ... Animation Delay: ... rts Which was causing the subroutine to exit all the way back into the Vertical Blank subroutine calls. So now, when you move the joystick, the first frame from the correct table in ROM shows moving in the right direction, but there is no animation. All of this was discovered by using the Stella Debugger. It is very, very useful. I'd say anyone starting out making games should always look at the way their code is running in the Stella Debugger. I'd even say it might be worthwhile writing an interpreter for ASM files, so you don't have to get confused about the loss of labels and variable names. coloured_guerrilla008.asm guerrilla8_5.bin

My graphics are 25 pixels tall, and I really like the current way they look, so I'm not sure your method is going to work... Thank you so much for your help anyway. It's always reassuring to get a reply hahahah The frame counter I am using is a local one, within a subroutine. It is called "AnimFrameCounter". Should I be using a global frame counter, and only updating the animation frames ever 10 frames of that counter? Maybe that would work... I suppose what one should always do is check and see what's happening in the Stella Debugger.

I have put some more work in over the last few days! Please find the current version of the source code attached. I am currently at around 1KB. Changing the Main Game Mechanics I am going to change the main mechanic of the game from "snake with guns" to what a friend has labelled "lock and load". The reason for this change is not because I don't think I could have been able to make a kernel for "snake with guns", but because I liked the "lock and load" game so much better. This is how "lock and load" works: It's like scissors, paper, rock, except the three actions you can perform are: LOAD, BLOCK, and SHOOT. The game is normally played with two people on the bus, or on a park bench etc. You don't need any equipment at all. The point of the game is to shoot your opponent. However, before you do the SHOOT action, you must LOAD. You normally slap your knees twice in between rounds. So playing a couple of rounds would be like this: SLAP-SLAP LOAD SLAP-SLAP SHOOT In the game I have been taught, you can LOAD as many times as you like. However if you play LOAD, and your friend plays SHOOT, you lose. The idea is to LOAD while they are LOADING or BLOCKING. If you BLOCK, you will always defend yourself from a SHOOT. However if you always BLOCK, no-one will ever win, especially not you. The idea is to catch your opponent out LOADING while you shoot them. It turns out that this game mechanic can be very easily inserted into the current kernel I am writing. I will draw several Batista soldiers on one side of the screen, and several Guerrillas on the other, and the point of the game will be to instruct each of your guerrillas to either LOAD, BLOCK or SHOOT, and a simple AI will control the soldiers. The point of this part of the game will be to defeat the Batista soldiers. Stable Screen I am currently drawing around 257-259 lines. This is not the proper 262. I need to fix this. Movement and Animation This part of the game I need a little help with. I am able to get a little Che to move around the screen, but: I cannot seem to set the limits of the current screen properly - i.e. the bottom of the screen I have set does not actually appear to the bottom of the screen I want to display one frame of movement every 10 screen frames, but the 10-frame delay routine I have written doesn't seem to work properly. It is especially bad when you hold the controller diagonally. What I want to do is: (a) move Che every frame, but (b) display a new frame of movement every 10 screen frames. Currently my code allows Che to move, but the animation isn't working at all. Would it be alright if someone took a look? Any suggestions about how to cycle the animation every 10 frames IF Player0 is moving? Perhaps what I could do is increment a frame counter and then divide it by 10... Anyway it's the end of the day here, I just wanted to put this up to show this project is still alive. coloured_guerrilla007.asm seventhversion.bin

Looks great!

Yeah! I did notice that! You're totally right. Thanks man!!

Wow this is really amazing...

You need to go through the interactive questionnaire and describe the appearance of the font. It's a little like Animal, Mineral, Vegetable - answer enough of the questions about the font and you'll identify it. If that doesn't make any sense I'll go through the questionnaire tomorrow and try and identify the font myself. For instance the font is a DISPLAY font, and not a TYPE font. It's made for titles. It is also a SANS SERIF font, meaning it doesn't have serifs. These are all the kinds of questions the website will ask.

Good luck! I can try and help debug if you need! I'm always looking to improve my skill.

I think of it a little bit as cheating - instead of always drawing everything you need to on the scanline, you just ... don't draw certain things. SpiceWare's semi tutorial "Stay Frosty" on his blog has flickering sprites. They're little balls of fire, so they look natural while flickering. An NTSC Atari will draw one frame every 1/60th of a second, so flickering is some smaller amount of presence on the screen. Instead of 60Hz, the frequency of flickering would be less, like 30Hz.

Looks great!

Yeah! Use the interactive questionnaire on http://www.identifont.com

I think there's a website where you can identify fonts... Is it called identifont?? Give me a second...

I learned a lot by reading this thread!

I remember there being some discussion about the TIA sound polynomial counters in the Stella Mailing List. If you search "polynomial" in my Commo Dig you should see the discussion I logged down. Not sure if it's useful though.

If I'm being totally honest, I don't actually have any wishes for any more hardware improvements to the 2600. Hahaha. The limitation is a really nice challenge, and in many ways the 2600 really does take care of some of the most difficult stuff for you. More sprites would be nice, but you really can cheat your way out of that issue. Ah! I just realised what I'd improve. More RAM, and bigger supported ROM sizes than just 4KB - although bank switching isn't really a big issue...

Like today, I invited a friend over to play some Sega Megadrive, and as it came close to a certain hour we had to break from playing so he could log into his MMORPG and "collect some items". I thought it was really bizarre that you'd pause a social interaction with a friend in order to log into your virtual life and do something at some scheduled hour. It seemed like the game was work, something you show up on time for. The game was playing HIM, really.

I agree with this.

Yeah, I guess I am pretty moralistic about games. The first thought I had to reply to this was that games are now becoming mixed with insidious forms of behavioural science which causes you to become addicted, but that's not really a new phenomenon at all. Games even before the semiconductor era were designed to addict and manipulate people, so such an issue is not even unique to the modern age. I still have this hunch that something has gone wrong with modern home gaming. Maybe despite by radical politics I'm fairly traditionalist about my video game aesthics. I do concede that open world games aren't a terrible genre. I suppose it's not the aesthetics of modern gaming I have an issue with, but the way they're socially deployed. I guess I have to think more about this.

For those wanting to follow along, these files contain the horizontal and vertical graphics data for the Che character. I think I may be able to reduce the amount of ROM needed by reflecting the first frame of the up and down graphics respectively. Vertical_Graphics.asm Horizontal_Graphics.asm

Here are the graphics for Che moving vertically. I have the graphics for horizontal movement but I forgot to take a screenshot.

Well, this is a huge step forward for me - I managed to set the pointers completely correctly in order to display a multi-coloured Che Guevara on the screen. I got there through sheer trial-and-error. It turns out the pointer needs to be set like this: LABEL - (Playfield Height) - 1 + (Y Position) - 1 Which works out to this: LABEL - 192 - 1 + 80 - 1 Anyway here is a screenshot of my progress, and here is my source code. Thank you so much to everyone who is teaching me the skills to figure out how to solve problems on my own. coloured_guerrilla006.asm