Graphics Mode 12 Overlay Code Required

[snicklin]

Hello everyone, I am currently writing a car racing game in 'C' for the Atari 8 bit (similar to Grand Prix Simulator but with 4 way scrolling).

 

The game uses graphic mode 12 (antic 4). Does anyone have any 'C' or assembly code available for overlaying a graphic over another without destroying the background? i.e. Like a sprite routine?

 

If you need any more information then please let me know.

[snicklin]

By the way, I'm not after some massive all-super routine, I just want something that'll display a single graphic over the top of other characters without destroying what is underneath. I'd use colour 0 as a transparency colour.

[Rybags]

You want a soft-sprite routine.

 

IIRC, there's one in the examples in the MADs Assembler download.

 

Transparency? You define masks seperate to the sprite definitions that take care of that.

[Heaven/TQA]

why are you not using hardware sprites?

 

soft-scrolling plus soft sprites will be challenging?

 

but in assembler you would use masks

[snicklin]

> why are you not using hardware sprites?

 

I will be using hardware sprites for the cars which'll go around the track. I'm planning on having 4 cars with 3 of them being computer controlled. When the game is commenced from the title screen, I'd like a big "GO!" sign to scroll down from the top of the screen to the centre, before disappearing.

 

> soft-scrolling plus soft sprites will be challenging?

The game will not be scrolling at the time of the overlay graphic coming onto the screen. I don't want to make life too difficult!!

 

> but in assembler you would use masks

I've already tried implementing a masking routine though it's giving me some weird results at the moment. I cannot see what is wrong with it...

[snicklin]

You want a soft-sprite routine.

 

IIRC, there's one in the examples in the MADs Assembler download.

 

Transparency? You define masks seperate to the sprite definitions that take care of that.

 

Thanks Rybags, I'll take a look at the MADs Assembler, it may well come in very useful. As I say in my other post, I've already had a go at a masking routine, which is giving me trouble. Rather than go through a load of code on here, which is rather cumbersome, I wondered if somebody had already done a nice, quick routine which I could nab!

[Heaven/TQA]

sure... but it would be in assembler?

[+Philsan]

It would be nice something like C64's Slicks.

You can download it here: http://www.c64.com/

Edited August 1, 2009 by Philsan

[snicklin]

Ooh, that'd be fine! I'll just embed it into my 'C'. Later on I may refine how I handle the code. Thanks!

[snicklin]

As for being like C64's Slicks, I've never seen that game before but it does look quite interesting from the screenshot. I was thinking of something like that (from what I can see on the screen) but based more around grass in the background rather than concrete.

 

I should knock-up some screenshots to show you all what I have done so far.

[+Philsan]

You should try Slicks with Vice. Very good playability and graphics.

The only problems are the 6 multicolor sprites.

Edited August 1, 2009 by Philsan

[snicklin]

Here's a screenshot. It currently only has 1 car (which looks quite like the ones in Grand Prix Simulator). Please excuse the weird colour scheme. This is me testing out my DLI's (which have a minor timing problem).

[snicklin]

You should try Slicks with Vice. Very good playability and graphics.

The only problems are the 6 multicolor sprites.

 

I'll take a look some time, I want to do my research into similar games and make sure I can get as many good features as I can from other games. It's a lot of hard work though. I probably won't attempt 6 multi-coloured sprites, I'll just get the idea from the game and work on that.

[snicklin]

Here's a compressed .XEX file. Use your joystick to move around.

 

There's some dodgy DLI's for extra colour (which'll be refined later). There are pools of water which the car will be able to drown in, and there's some rubbish on the track near the top left - that's my testing of my non-working software sprite routine.

 

I've developed some music which is not linked into the game yet, that's also in there. This'll be for the title screen when I've added one in.

 

As you can see, this is VERY much in the prototype stage. It is named "Atari Formula 1" for now...

af1.zip

[snicklin]

I've developed a tile system so that it only uses 240 bytes for the level information. I'll have around 10-20 levels in the finished version. I'd also like to add diagonal sections of track, not just the vertical-horizontal ones that we have at the moment.

 

If you wonder what the vertical/horizontal bars across the track are, they'll be bridges.

Edited August 1, 2009 by snicklin

[+Philsan]

Awesome work!

Where do we find your other game "Football Fantasies"?

[snicklin]

Awesome work!

Where do we find your other game "Football Fantasies"?

 

Unfortunately I do not have a copy of it. It's available in Dean Garraghty's PD collection (http://www.dgs.clara.net/list1.htm PD Disk 185). I did once have a copy for the PC but I couldn't get it working in my emulator and have since lost it!

[Rybags]

Suggestion - to make things easier when doing softsprites in this game, you're probably best off using a "World coordinates" system.

 

Rather than the pain of working out differences due to scrolling, just render everything using X/Y relative to the origin of the top right of the game map, rather than whatever the screen happens to be showing.

 

Of course, you probably want to do some sort of bounds checking as well so that you don't waste time rendering stuff that's not visible.

[snicklin]

Suggestion - to make things easier when doing softsprites in this game, you're probably best off using a "World coordinates" system.

 

Rather than the pain of working out differences due to scrolling, just render everything using X/Y relative to the origin of the top right of the game map, rather than whatever the screen happens to be showing.

 

Of course, you probably want to do some sort of bounds checking as well so that you don't waste time rendering stuff that's not visible.

 

Hi Rybags, thanks for the tips here. I think I will do it that way except that I'll work it out from the top left (as that's where my screen memory starts - gets less confusing).

 

As for bounds checking, as I've done some 3D graphics programming before, I've come across this concept before therefore I should think about using it here. The only problem may be though, is if 1 car is on screen (out of 4 cars) then that car might magically speed up!! Of course the player will love that, but it won't be correct. Or maybe I can use the spare CPU cycles for something else? (which'll make coding become somewhat more complex).

 

Cheers for the tips!

[Heaven/TQA]

looks good so far...

 

but as you are planning to use players for the cars I noticed that you are not using overscan mode... then you will have to deal with clipping/masking as the players can move into the borders of the screen... and that will look odd.

 

two simple solutions:

 

- mask out players by putting missles on the left/right corner and set the priority that the cars will move below before repositioning

- simply do a poke $d400,63 or poke 559,63 and borders are gone...

[snicklin]

looks good so far...

 

but as you are planning to use players for the cars I noticed that you are not using overscan mode... then you will have to deal with clipping/masking as the players can move into the borders of the screen... and that will look odd.

 

two simple solutions:

 

- mask out players by putting missles on the left/right corner and set the priority that the cars will move below before repositioning

- simply do a poke $d400,63 or poke 559,63 and borders are gone...

 

Ahh, thank you for the tips here (there's so many helpful people on this forum!). I've not really played with the PMG's much yet, as you can see I've only put the car into place, just to see if I could get PMGs working. I would have come up against that problem that you mention though with the borders - but now I won't!

 

I'm also going to have to work out the priorities of the PMGs. My bridges are all of one colour, so I should be able to give them priority so that the cars will disappear behind them.

[+Philsan]

Instead of classic top-down view it would be nice an isometric view.

TOCA Touring Car Championship (Gameboy color, very good game)

[snicklin]

Instead of classic top-down view it would be nice an isometric view.

TOCA Touring Car Championship (Gameboy color, very good game)

 

Well, it'd be quite a lot of work for me to change it all around like in that screenshot, so I won't be doing that, but I am looking at getting a slight element of 3D into the game. I'm looking at doing some advertising boards in the background and maybe a stand for all the spectators to sit in.

 

By the way, I've managed to do my software sprite code and managed to do it in 'C'. All the code was already there but I found that I was using an unsigned char instead of an unsigned int for something and therefore it was messing everything up. I'm now working on making it more efficient as it is somewhat slow and seems to be let down by a bug in CC65. The code is a little inflexible at the moment in that my software sprites cannot be placed anywhere on the screen but only in place of a character (in other words, I can place a sprite on every 8th scanline). Once I've got further into development, I may well get the assembly code that CC65 has produced and see if I can hand craft sections of it. I'm no expert in 6502 assembly but I can read it and amend it a bit.

 

I've also changed (some but not all) of my code/data layout. I've got fonts loading in from file at build time now rather than from arrays in the code. I still need to get my tile data loaded in from file (at build time).

[miker]

Any progress?

[snicklin]

Any progress?

 

Not in the last few weeks but since previously, yes. I couldn't show anything with screenshots as graphically it hasn't changed much. But I've been adding in a title screen, 4 cars (which all only face in one direction so far) and I've put a lot of "back end" code into place. I'm also trying to make the code more generic so that with a few changes to a 'C' #define, I can change the code altogether. The backend is being made generically so that I can apply it across to all different kinds of games.

 

The main area that I'm working on at the moment is how I am going to control the computer player's movements. My current idea is that I have a few set "target" points on the screen which each car moves to. In order to do this, I am using some integer mathematics as CC65 cannot use floats and would also slow the code down a lot.

 

I'm coding it also so that you can have 1 or 2 players playing. If 1 player plays, then the screen used is full screen. If 2 players play, it'll be a split screen. Though to do this, I'll need to write a PMG multiplexer for the lower screen (or limit 2 player games to 2 cars). One idea I have is that as soon as one of the players completes the course, the screen auto-switches to full screen.

 

I've cleaned up the code a lot and have done things a lot more efficiently than I originally had it - it's just a shame that I cannot show any progress on the screen....