News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Quick question on Renegade/Target Renegade graphics

Started by sigh, 17:17, 07 December 10

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sigh

Hi. Would really appreciate some help on the graphic resolutions on these two games.

I want to ask what resolution Renegade and Target Renegade was made in. Its just that they are both using 16 colours but are larger in width than Mode 0 allows - even in overscan. If it were made using a mix of 2 resolutions (like "Sorcery") what were those resolutions?

Thanks!

Edit: I gave most of the games away to forum members, so I cant take a look!

arnoldemu

Quote from: sigh on 17:17, 07 December 10
Hi. Would really appreciate some help on the graphic resolutions on these two games.

I want to ask what resolution Renegade and Target Renegade was made in. Its just that they are both using 16 colours but are larger in width than Mode 0 allows - even in overscan. If it were made using a mix of 2 resolutions (like "Sorcery") what were those resolutions?

Thanks!

Edit: I gave most of the games away to forum members, so I cant take a look!
Both use mode 0 for the main play area (sprites and backgrounds).

The screen is actually reduced down from normal mode 0 (160x200) to (128x192) to be almost the same as a spectrum screen size.

There is a mode change for mode 1 for a panel at the bottom.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Thanks for the info.

That is so strange! Graphically the game is using wide pixels at being 160 x 200, but how did they make the width longer? Was is some how swapped around to 200x160 instead?

arnoldemu

Quote from: sigh on 17:37, 07 December 10
Thanks for the info.

That is so strange! Graphically the game is using wide pixels at being 160 x 200, but how did they make the width longer? Was is some how swapped around to 200x160 instead?
Hmmm.. as far as I am aware the width of the screen is smaller than normal.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh


fano

It's like there is a confusion between mode and resolution.
Target Renegade uses 32 chars screen width that gives 128 pixels width in mode 0 for game zone and 256 pixels width in mode 1 for the osd/hud.
Real resolution on CPC depends diplay mode (0,1,2) and screen width settings (CRTC registers).If you consider resolution is pixel size , Target Renegade uses differents resolutions (not if you think like CPC/CRTC lol)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

sigh

Ahhh...I think I'm starting to understand. I'm thinking of creating some graphics for a CPC game. So I could use 320 for the hud and 160 pixels wide for the in game screen. For the height (it will have scrolling)  I can have it as 100 pixels wide in game and 200 for hud (the game screen being in the middle).

Okay, thanks

redbox

Quote from: sigh on 19:42, 07 December 10
Ahhh...I think I'm starting to understand. I'm thinking of creating some graphics for a CPC game. So I could use 320 for the hud and 160 pixels wide for the in game screen. For the height (it will have scrolling)  I can have it as 100 pixels wide in game and 200 for hud (the game screen being in the middle).

Yes, this is right, but don't forget that the 160 pixel width screen (MODE 0) means the pixels are actually 'double length' in appearance, so if you draw all you stuff nicely in a normal pixel editor it will look stretched on when you transfer it to the CPC.

An easy way to design graphics for this mode is simply to use double pixels in a paint program, but remember this is only horizontally and not vertically.

Have a look at this graphic on Grim's website to see what I mean.

fano

This is a solution , some editors like The Gimp or Grafx2 have special settings to draw wide pixels (mode 0) or tall pixels (mode 2)

( A little advertising for my prefered pixel editor for CPC/+ http://code.google.com/p/grafx2/  :-* )
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

andycadley

It's also worth remembering, if you're planning to do a game with a split mode display, that it requires reasonably accurate timing to change the display. This means you either need to syncronise the change with a interrupt or will need some very accurate timing routines to keep things working.

redbox

Quote from: andycadley on 22:31, 07 December 10
It's also worth remembering, if you're planning to do a game with a split mode display, that it requires reasonably accurate timing to change the display. This means you either need to syncronise the change with a interrupt or will need some very accurate timing routines to keep things working.

True, unless you use a Plus  8)

sigh

Thanks for the info!
I'll do the graphics and an animated  mock up/demo first to show how it would play. Hopefully that will gather some interest for a programmer to take it on.

Thanks!

arnoldemu

Quote from: sigh on 01:18, 08 December 10
Thanks for the info!
I'll do the graphics and an animated  mock up/demo first to show how it would play. Hopefully that will gather some interest for a programmer to take it on.

Thanks!
I am a programmer...

I'm working on a game at the moment that will be finished in the new year... after then... well ;)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: fano on 20:28, 07 December 10
This is a solution , some editors like The Gimp or Grafx2 have special settings to draw wide pixels (mode 0) or tall pixels (mode 2)

( A little advertising for my prefered pixel editor for CPC/+ http://code.google.com/p/grafx2/  :-* )
Indeed if you want to use gimp:

http://www.cpctech.org.uk/download/gimp.zip

These may help

when you create a new image set the image size, then in advanced options set x resolution to 36 and y to 72.
Then to to view "dot for dot".
You'll see the difference quickly and making gfx will be easy too.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Sykobee (Briggsy)

Quote from: fano on 20:28, 07 December 10
This is a solution , some editors like The Gimp or Grafx2 have special settings to draw wide pixels (mode 0) or tall pixels (mode 2)

( A little advertising for my prefered pixel editor for CPC/+ http://code.google.com/p/grafx2/  :-* )


Shame that the URL isn't working - very odd for Google. Will look later as it looks like a tasty app.

fano

Weird it works fine here (SeaMonkey 2.0.10)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Sykobee (Briggsy)

Quote from: fano on 18:57, 08 December 10
Weird it works fine here (SeaMonkey 2.0.10)


Yeah, it's working now. Thought it was a weird website issue. It's nice to have something like DPaint again, although the UI is quite jarring on a large monitor.

sigh

I've been doing some sprite poses for the demo (scrolling beat em up), but I was wondering that when creating enemies or the 2 player mode, did programmers use code for intricate palette swaps? I notice that in the Renegade games, there were 2 types of enemy per level characters and a boss. They had 1 or 2 attack moves. The walk cycles were the same for most of the characters. Did the programmers just keep the legs the same and palette swap the top half of the body, or did new animation have to be created for each character?

I'm using mode 0 16 colours. I'm thinking that this may have to be a 128k only game! I'll show something soon....

arnoldemu

Quote from: sigh on 13:08, 10 December 10
I've been doing some sprite poses for the demo (scrolling beat em up), but I was wondering that when creating enemies or the 2 player mode, did programmers use code for intricate palette swaps? I notice that in the Renegade games, there were 2 types of enemy per level characters and a boss. They had 1 or 2 attack moves. The walk cycles were the same for most of the characters. Did the programmers just keep the legs the same and palette swap the top half of the body, or did new animation have to be created for each character?

I'm using mode 0 16 colours. I'm thinking that this may have to be a 128k only game! I'll show something soon....
Well, mostly the game was memory limited.

If you consider that these games used double buffer to stop sprite flicker, then almost 32k can be taken away immediately for screen data. If you reduce the screen, as they did, and then use software scrolling, you use less ram. The remaining invisible ram can be used to store code, graphics and data.

It is possible they reused the leg graphics and animation where they could, so that there is only one set of leg animation.

I didn't check, but it is possible that the final sprite you see is a composite of more than one sprite, draw to the screen in a certain order.
e.g. leg sprites, then body sprite, then arm sprites.
In this way you compose the final sprite out of other bits.

I know that in the original renegade there are some conversion arrays used to draw the sprite mirrored (so they only stored the graphics for the character pointing to the right and at runtime they used the array to mirror it so the character is pointing to the left).
Again this was done to fit it all into ram.

Also, recolouring of sprites when they are drawn to the screen is possible, normally this is not done by changing palette colours, but recolouring using a in-memory conversion array. If you choose to do it by changing palette colours, then you are then limiting the number of colours you can have for background, so then this is a tradeoff between colour and speed.

What I am saying is that they probably re-used a lot and did a lot at runtime because they just didn't have the ram free to do otherwise.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Aaahh! So the best thing for me to do be to cut the characters into pieces and have a programmer to use an array to change the colours. That makes sense. You stated the trade off in colours, but I'm using 16 for sprites and backgorund, like the other Renegades. I'l give the characters a maximum of 4 frames for each attack move. I think this is roughly the amount of frame for moves in renegade games. Maybe best to follow these methods to get it target renegades 2 player with 4 enemies on screen at once before I start trying to add extra frames for smoothness.

Really appreciating the help!


arnoldemu

Quote from: sigh on 13:59, 10 December 10
Aaahh! So the best thing for me to do be to cut the characters into pieces and have a programmer to use an array to change the colours. That makes sense. You stated the trade off in colours, but I'm using 16 for sprites and backgorund, like the other Renegades. I'l give the characters a maximum of 4 frames for each attack move. I think this is roughly the amount of frame for moves in renegade games. Maybe best to follow these methods to get it target renegades 2 player with 4 enemies on screen at once before I start trying to add extra frames for smoothness.

Really appreciating the help!
One thing you should consider is that each sprite should use only 15 colours. Pen 0 should be reserved for transparency.
It is quicker and takes less ram if you define them this way. The alternative is that mask graphics would have to be stored, and this would almost double the amount of ram your sprites take up. The backgrounds can continue to use all 16 colours.

The other thing I think that would really help is possible a design of how the characters react to the player's movement and attacks.

I've seen quite a lot of Amstrad beat em ups, more side ways on, where every character in the game has the same moves and can be defeated in the same way. In addition it is sometimes possible to run your way through most of the level, the games like this (e.g. Dick Tracy) I find are boring to play.

So as well as graphics, please consider writing something about this too.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

The reaction from the enemies will be a hit animation, stun animation, duck/dodge animation and an animation with them on the ground. I can't program which is why I'm doing an animation demo and hopefully it will make sense. I think when the reaction takes place might be more of a program thing.

My sprite has 13 colours and wont have anymore. I was thinking that if I were to have the sprites in mode 0 but the background using mode 1 4 colours, would that save on ram? The renegades have only the hud in mode 1 4 colours.


arnoldemu

Quote from: sigh on 15:02, 10 December 10
The reaction from the enemies will be a hit animation, stun animation, duck/dodge animation and an animation with them on the ground. I can't program which is why I'm doing an animation demo and hopefully it will make sense. I think when the reaction takes place might be more of a program thing.

My sprite has 13 colours and wont have anymore. I was thinking that if I were to have the sprites in mode 0 but the background using mode 1 4 colours, would that save on ram? The renegades have only the hud in mode 1 4 colours.
re the enemies: the animations are fine.

sprites/background: You can't mix mode 0 and mode 1 in this way. The sprites have to be the same resolution as the background.
You could store the background using 4 colours and convert at runtime, but it would slow the game down and could look ugly?

the hud is a seperate part of the screen, so it can be mode 1 and use 4 colours.

13 colours is fine for the sprite :)

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Okay thanks. I thought mixing the modes this way would speed up the game but it seems I was wrong. Seperating the body parts reminds me of a flash game I worked on! ;D

arnoldemu

Quote from: sigh on 16:36, 10 December 10
Okay thanks. I thought mixing the modes this way would speed up the game but it seems I was wrong. Seperating the body parts reminds me of a flash game I worked on! ;D
I was thinking... If I could code some very simple programs, what would help to visualize the things we have talked about?

For example, I could do a program that showed the Renegade sized screen, I could also do a program the reproduced the mode split, and at the same time I could colour the border in a way so you can see where the split comes, so you can get an idea of the screen area you can work with.

I've done some programming examples before, so I could adapt these to help designers and artists like yourself to understand what the cpc can do and how you can work with it?

Would this kind of thing help?

I am not thinking of a complete development environment, but more a few programs you can run (on an emu or real machine) to see visually some of the things that have been talked about here.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Powered by SMFPacks Menu Editor Mod