Guru
Joined: 13/08/2020
Location: CanadaPosts: 490
| Posted: 01:00am 08 Jan 2025 |
Dev update:
My current problem is that the screen redraw is very slow, taking about 250 milliseconds to redraw the full screen. Normally this wouldn't be much of an issue for a turn based game (the screen isn't being redrawn 99% of the time), but I want to improve it for two reasons.
1. When the player moves their ship, there is a 250ms lag between the keypress and the ship moving. I know that sounds small, but it is noticeable and makes the whole program feel sluggish.
2. I want to do some fairly high speed animations (explosions, warp etc.). And 4 frames per second just isn't going to cut it.
On that note - one of the things I'm trying to achieve with the retro-ASCII graphics, is to lull the player into buying into the old VT terminal interface, and then when something spectacular happens, an ASCII ship explosion for example, it has far more impact.
If you ever watch the movie Galaxy Quest, it uses this downplaying method to great effect. The first part of the show, when they are on the TV show is shot in 4:3 ratio. You don't really notice it. Then it opens up to slightly widescreen when they are out of the show and in the real world. But when Tim Allen's character first sees the hanger doors of the space ship open to the void of space, the image matches the doors opening to expand to full widescreen. That's the kind of wow factor I want recreate - where we're showing people what looks to be a text based display - but is in fact a fully bitmapped display.
Of course, I could just go straight to using 65K colour graphics, but that would ruin the effect. I have to walk the fine line between this being a retro-text terminal display… but also able to do some cool things with those text characters.
Before I dive into specifics of my speed issue, I figure that some very basic knowledge might help if you're new to the CMM2/games programming.
Therefore, I'm going to give a quick overview as to how the graphics are organised. If you're familiar with double-buffering and blitting, then you can safely skip this post and go on to the next one. You won't be missing out on anything.
We're using Mode 1 - 16 bits for the graphics. That is 800x600 pixels with 65,000 colours.
Because we are using a font that is 10x20 pixels, this gives us about 80 columns of text across the screen and 30 lines. It's slightly less because of the Bezel image I'm using around the outside to make it look retro.
The 1st Generation CMM2 can store 3 of these Mode 1 graphics pages in memory (numbered 0, 1 & 2). I could increase this to 6 pages by dropping down to 8-bit/256 colour mode - but I really like the bezel (which doesn't look as good in 8 bit mode), and because we are using fonts instead of bitmapped graphics, we don't really need the extra pages.
We can think of these three pages of video memory as three blank sheets of paper. We can show any of them to the user at any time. If we were just to use page 0, then we would be using one sheet of paper - drawing each frame, then erasing it, then drawing the next frame over the top of it. Unfortunately, the user would see the page being cleared for a split second before everything is redrawn, and this would be an annoying flicker on the screen with each redraw.
So, to get rid of this flicker, we alternate between drawing on pages 0 and 1, and we show the user the other page. So, if I want to refresh the image on the screen, I show the user page 1, and I draw on page 0. When I have finished drawing, I swap the sheets of paper over and show the user page 0 and clear page 1 ready for the next image. We keep swapping back and forth like this and the user sees a seamless animation with no flicker.
The call to change which page the user can see is almost instantaneous - so you can achieve very high frame rates with this method. This is very common in games programming and is called double-buffering and is critical in action games where sprites are moving around the screen many times per second.
Next, I'm going to mention Blitting a lot. Blitting is simply the method used to copy one piece of graphics memory to another. So, I could have an image of a space ship on graphics page 2 at position 0,0 with a width and height of 50 pixels. I can "blit" that rectangular image very quickly from page 2 onto any location on the draw screen. The original copy stays on page 2, but by doing this I can quickly "draw" multiple graphical elements on my screen. So, for something like space invaders for example, we would have one image for the space invader on page 2, but we would copy it 20 or 30 times on to the draw screen to build up the image of a swarm of separate invaders.
A typical sprite sheet is shown below. By blitting portions of it on to the game screen we can quickly build up quite a complex image.
The final thing to know about blitting is that it's very quick if you're overwriting the entire rectangle. However if you want to blit a rectangle with a transparency (for example, a player sprite walking in front of a building), then one of the colours (black) will be designated as "transparent" and will not be copied over to the new image.
In the images below, you can see what would happen if we didn't use transparency (left image) when the player character starts to erase the door image. So we would draw the player character with transparency, so that we can do not destroy the image behind the player sprite.
The only thing you need to know about this is that transparency does slow down the draw speed a little bit.
That's it - you're now up to speed on everything you need to know to understand my next post.