Jump to content
IGNORED

Atari 2600 Soccer


Retrofan

Recommended Posts

Because of the FIFA soccer world championship I played my Atari soccer carts (Pele's Soccer, International Soccer/Football and Real Sports Soccer) again. But non of the games is really good. :( I think, it could be a much better soccer game for the VCS. Because I had fun viewing the matches on TV I made a mockup screen for my/your pleasure. Maybe someone want to make a homebrew version of soccer (it would be the first homebrew sports game?) ... ;)

 

Have fun

 

And here is the mockup:

 

SoccerWM2600.gif

Link to comment
Share on other sites

Ronaldo Soccer sounds good, why not? The brasilian or the portogese Ronaldo? :)

 

Here is a screen which shows the whole playfield with all 22 players. The field is separated in 5 areas (black lines show it): 2 for the goal keepers, 2 for defence/attack (each with 3 players) and one middel field (with 4 players). The players can't go out of their area and they were controlled together. So you have to pass/shoot to other players when you want to go to the goal. When you are in defence you can control the goal keeper by pressing the button while moving the joystick.

 

The playfield is vertical because of the softer scrolling abilities. in each scanline there are max. 2 different and 2 identical players. The background has 2 colors in one scanline. I think, it would be a possible game.

 

What do you think?

 

SoccerSystem.gif

 

have fun

Edited by Retrofan
Link to comment
Share on other sites

the ball would take on the color of the playfield - the light green.

 

OK, ball and playfield lines are white now. The lines could be solid but then the ball would be invisible if it is on the line. And a small animation (it could be better with more than 2 frames).

 

Soccer_anim.gif

Link to comment
Share on other sites

The field and players are doable. Having the ball white is another story - the ball would take on the color of the playfield - the light green.

Actually, he has a couple of options:

 

1. Recolor the playfield for the ball rendering, then set the color back before the sides of the field are reached.

2. Use missile graphics or sprite graphics.

3. Use some really cool (and complex) looking code ala M-Network to switch between ball, missiles, and sprites as needed.

 

None of the above are for the feint of heart, of course, but then neither is writing a Soccer game for the 2600. :)

 

Am I the only one who's really tempted to pop an embedded microprocessor into a cart to handle all this stuff faster and easier? Programming would be a little tricker (since you've got an incompatible, embedded microprocessor generating code to run on the 2600's 6507), but the results could take the machine to nearly NES levels. (Pitfall II anyone?)

Link to comment
Share on other sites

Am I the only one who's really tempted to pop an embedded microprocessor into a cart to handle all this stuff faster and easier? Programming would be a little tricker (since you've got an incompatible, embedded microprocessor generating code to run on the 2600's 6507), but the results could take the machine to nearly NES levels. (Pitfall II anyone?)

Well, I think supercat and Delicon have both discussed and/or worked on similar concepts. See, especially, the Chimera.

 

Also..

1. Recolor the playfield for the ball rendering, then set the color back before the sides of the field are reached.

That would be doable, except that the lines on the field aren't just the sidelines.

3. Use some really cool (and complex) looking code ala M-Network to switch between ball, missiles, and sprites as needed.

What do you mean by this?

Edited by vdub_bobby
Link to comment
Share on other sites

Well, I think supercat and Delicon have both discussed and/or worked on similar concepts. See, especially, the Chimera.

I'll have to search for that. Thanks! :)

 

 

3. Use some really cool (and complex) looking code ala M-Network to switch between ball, missiles, and sprites as needed.
What do you mean by this?

Basically, you switch how you render the ball depending on the context. e.g.:

 

1. Is there only one other sprite on the soccer ball's scanline? If yes, then use a sprite to render the soccer ball.

2. If there are two sprites, is the soccer ball far enough away from a player to recolor a missile? If yes, then use a missile.

3. If there are two sprites, and the soccer ball is too close, and the playfield is far enough away, use a ball and recolor the playfield on the fly.

4. If none of the above conditions are met, use a ball, but either don't render the playfield for those scanlines, or change it to white for those scanlines. (Alt. Use mutlisprite ficker in this case.)

 

I mentioned M-Network because they were famous for pulling tricks like this to prevent flickering. :)

Link to comment
Share on other sites

1. Is there only one other sprite on the soccer ball's scanline? If yes, then use a sprite to render the soccer ball.

2. If there are two sprites, is the soccer ball far enough away from a player to recolor a missile? If yes, then use a missile.

3. If there are two sprites, and the soccer ball is too close, and the playfield is far enough away, use a ball and recolor the playfield on the fly.

4. If none of the above conditions are met, use a ball, but either don't render the playfield for those scanlines, or change it to white for those scanlines. (Alt. Use mutlisprite ficker in this case.)

 

I mentioned M-Network because they were famous for pulling tricks like this to prevent flickering. :)

That's insane. What game ever did anything like that? If you are referring to Lock 'N' Chase or Dark Cavern, well, those did some fancy-pants tricks to avoid flicker but nothing as crazy as what you are talking about. :o

Link to comment
Share on other sites

That's insane. What game ever did anything like that? If you are referring to Lock 'N' Chase or Dark Cavern, well, those did some fancy-pants tricks to avoid flicker but nothing as crazy as what you are talking about. :o

As you said, Lock 'n' Chase, Dark Cavern, and Burgertime did similar tricks. I'm just a little crazier than they are. BWHAHAHAHA!!! :evil:

 

The idea isn't too bad if you build a kernal capable of interpreting commands from the stack. You simply run a routine during the VSync to populate an area of memory with the commands, then set the stack pointer to the beginning of your instruction list. Each time an item (sprite, missile, or ball) completes its task, it pops the next set of instructions off the stack.

 

The brilliant part about making it stack-based is that you can reset the stack and rerender the exact same frame! This is great for taking turns between running logic during VSync and running the kernal preparation code. The only downside is that any flicker used would be at 15Hz rather than 30Hz. Which might look kind of bad. :(

 

I've been working on a multisprite kernal to do something similar inside the standard 128 bytes of memory. I'm trying to work out about 9 sprites on the screen simultanously. I'm not sure if it will ever get done (especially since I have a lot of other things that take priority over this work), but it will be pretty cool if I managed to finish it. :cool:

 

A SARA chip would obviously have made my life easier, but I started before CPUWiz's annoucement. :sad:

Link to comment
Share on other sites

That's insane. What game ever did anything like that? If you are referring to Lock 'N' Chase or Dark Cavern, well, those did some fancy-pants tricks to avoid flicker but nothing as crazy as what you are talking about. :o

As you said, Lock 'n' Chase, Dark Cavern, and Burgertime did similar tricks. I'm just a little crazier than they are. BWHAHAHAHA!!! :evil:

 

The idea isn't too bad if you build a kernal capable of interpreting commands from the stack. You simply run a routine during the VSync to populate an area of memory with the commands, then set the stack pointer to the beginning of your instruction list. Each time an item (sprite, missile, or ball) completes its task, it pops the next set of instructions off the stack.

 

The brilliant part about making it stack-based is that you can reset the stack and rerender the exact same frame! This is great for taking turns between running logic during VSync and running the kernal preparation code. The only downside is that any flicker used would be at 15Hz rather than 30Hz. Which might look kind of bad. :(

 

I've been working on a multisprite kernal to do something similar inside the standard 128 bytes of memory. I'm trying to work out about 9 sprites on the screen simultanously. I'm not sure if it will ever get done (especially since I have a lot of other things that take priority over this work), but it will be pretty cool if I managed to finish it. :cool:

 

A SARA chip would obviously have made my life easier, but I started before CPUWiz's annoucement. :sad:

What do you mean, "stack based?" How is that different from running your kernel from RAM?

Link to comment
Share on other sites

What do you mean, "stack based?" How is that different from running your kernel from RAM?

 

This is simplified to just the sprites, but here's the idea:

 

Step 1: Build a list of commands in memory.

Step 2: Set the stack pointer to the beginning of this memory.

Step 3: Pop the Y position and the cycle count for the next RESP/HMOVE for player0

Step 4: Pop the Y position and the cycle count for the next RESP/HMOVE for player1

Step 5: After the RESP/HMOVE, pop the Y start and Y length value for rendering player0.*

Step 6: After the RESP/HMOVE, pop the Y start and Y length value for rendering player1.*

Step 7: Goto Step 3

 

While I've got it neatly laid out as one thing happening after another, in actuality, things would happen on demand. For example, the player0 sprite could be used twice between the time that player1 is RESP/HMOVEd and is actually rendered. The code to compute this list of instructions would have to understand the order of when they'll be popped to make certain that the right sprite pops the right instructions. It's tricky, but nothing a good sorting algo can't solve.

 

There are two primary issues to be aware of:

 

1. The renderer is only as good as the kernal preperation code. If the instruction list is populated poorly, the results will be poor. Thus the focus is on creating an algorithm that makes the most efficient use of resources available. As anyone who's done a compiler can tell you, this can be quite a chore. ;)

 

2. I didn't include any terminators in the simplified rendering loop above. Testing for starting and terminating lines is quite a burden in the kernal. I'm actually using something called "compiled sprites" so that different code can run on each scanline. Each sprite has setup code, scanline LDA/STA code (with the graphics data embedded in the LDA instruction), and post-display code. This keeps the cycle count very predictable from line to line, with no sudden branches that the kernal may or may not have time for. Unfortunately, it means that there are scanline "borders" around each rendering of the sprite where logic is being performed rather than rendering.

 

This concept differs from straight up memory accesses in that there's no record keeping for indexes or sprites rendered. The Stack Pointer takes care of that automatically every time the instructions are popped. For example, if the instructions occupy 0xF0-0xFF, each pop will move the Stack Pointer up one memory location from 0xF0 until 0xFF is reached. The post-rendering code has to be smart enough not to pop beyound 0xFF or the stack will overflow.

 

Does that make more sense? I know it may seem a bit alien, but it's pretty darn close to many low-memory interpreters. (Postscript comes to mind.)

 

Disclaimer: I'm still crazy, but hopefully in a good way. :D

 

* I actually use compiled sprites for predictable performance from scanline to scanline, but that's another story.

Link to comment
Share on other sites

Just found a minute to fix the display bugs on top of the screen, hope you don't mind icon_wink.gif

 

No problem. Thanks for the help! :D

 

Hello, I am very happy that there are more people than me who like soccer/football. Thanks to haroldoop for the first kernels, i like them very much. I hope the project will go further. :)

 

You're welcome. :)

 

BTW, here's another update. Not much done. Just tweaked the player graphics a bit, and added a walking animation.

soccer_kernel_test3.zip

Edited by haroldoop
Link to comment
Share on other sites

The field and players are doable. Having the ball white is another story - the ball would take on the color of the playfield - the light green.

 

What about using a "striped" playfield? If there's time, the scan lines where the playfield was displayed could have COLUPF set to light green and those where it was not have it set to light red (the ball would then be a mix of light green and light red, in other words, pretty whitish). If there isn't time to update COLUPF, just live with striped white field lines.

Link to comment
Share on other sites

The field and players are doable. Having the ball white is another story - the ball would take on the color of the playfield - the light green.

 

What about using a "striped" playfield? If there's time, the scan lines where the playfield was displayed could have COLUPF set to light green and those where it was not have it set to light red (the ball would then be a mix of light green and light red, in other words, pretty whitish). If there isn't time to update COLUPF, just live with striped white field lines.

 

:?

But then, the ball would be light green in the same lines where the PF is light green, and light red in the same lines where the playfield would be light red, which would send us back to the original problem: the ball would disappear in the playfield.

 

Oh, nevermind. I understood what you meant. You were giving a suggestion about how to make the playfield light green while keeping the ball white, correct? ;)

 

 

BTW Here's another update. Now it's starting to look like an actual soccer game!

soccer_kernel_test4.zip

Edited by haroldoop
Link to comment
Share on other sites

What do you mean, "stack based?" How is that different from running your kernel from RAM?

 

This is simplified to just the sprites, but here's the idea:

 

Disclaimer: I'm still crazy, but hopefully in a good way. :D

 

* I actually use compiled sprites for predictable performance from scanline to scanline, but that's another story.

 

This approach is workable and quite efficient in a way. I took this approach on the C64 and created a very nice 32 sprite multiplexer.

 

The idea comes from when you analyze what would be the ideal or 'perfect' code for every situation on any given frame.

 

Yes, it did occur to me that this is very similar to dynamic recompilation in emulators or JIT for interpreted languages.

 

I'd say it's only a small leap of logic to imagine a fast processor that does this work for you every frame and and produces the 6502 code. I proposed such an idea quite a number of years ago, to find that it had indeed been stewed on by others.

 

I found some resistance to the idea, and I kind of understand why. For a retro programmer part of the fun can be to work only within the confines of what was available or possible at that time. After all, why are we working on such an old obsolete system at all? If you introduce such liberal uses of modern tech where do you stop really, I mean I've seen 2600 case mods housing the latest Ghz CPUs...

 

Nevertheless, I wouldn't mind, I would grin actually, if someone was to actually produce such a monstrosity.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...