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 2 Guests are viewing this topic.

sigh

Wow!!! I don't want to take up any of your time, but that would be wonderful. I could then have an idea of the area that the game will take place in, along with the area of the hud. Would you like to see the example sprites to know their size?:



The colour palette is off for some reason and I think that it maybe an issue with my monitor calibration. Also, although the sprite is 13 colours, I think it may be showing 15 due to the background colour, as well as an extra shaded colour that shouldn't be there.

Sorry for the mess.

As you can see, I've started chopping the arms for re-use which then could be used as a composite.

Sykobee (Briggsy)

Nice sprites :-) Athough the one in the middle looks a bit like a protesting professor!

redbox

Quote from: sigh on 13:14, 11 December 10
Would you like to see the example sprites

Your sprites look really good, and it's nice to see new graphic artists working on the CPC creating original stuff.

sigh

Quote from: Briggsy on 18:17, 11 December 10
Nice sprites :-) Athough the one in the middle looks a bit like a protesting professor!

He's in trafalgar square trying to get those student fees down!

I have a few more poses to finish before I start animating(being hit etc) which I'm really looking forward to. I'm hoping to get the poses all finished for next week. Pixeling him lying on the floor was a nightmare in wide pixels which was definitely the hardest sprite to get right for me. His face just kept looking unreadable like a piece of vomit.
After the kick anim is done, if I separate the arm on the uppercut and use the body as a frame before the kick, but have it after the "being hit" frame, it could probably work as a judo throw. I'll probably have to go back and do a lot of pixel tweaking for these composites to work and save as much ram as possible.

Were there any CPC 128k only games? I had a CPC 464 but it had a 64K memory expansion, with most of that extra memory only being used for loading the whole game at once or having music/sound (shinobi, Gryzor, Dragon Ninja). But there didn't seem to be any other sort of graphical extras if my memory serves me right...

Edit: Ahhh, I just found this:

"Most games and software targeted the 64K RAM 464 and 664 models. Only a handful of titles exclusively targeted the 128K machines"
http://www.experiencefestival.com/a/Amstrad_CPC_-_The_CPC_family/id/4790558

MacDeath

Yeah, the 128K only games were almost non existant... this was surely the shame of the CPC... designed as a 64K computer... but so heavy on graphics that it just doesn't work that well.


Pirates! from sid Meyer is a 128K only game.
Perhaps the only one as I recall...

but otherwise the extra 64K were just used as you said : to get extra sounds or single loading.

sigh

That's a real shame! I've been catching up on information regarding the amstrad specs and it's shocking that the extra 64k wasn't exploited.





MacDeath

#31
I used to have a 6128 during my youth...
I share the feeling.

getting the game loaded once is not a big deal when you have a fast Disk Drive...
Getting games in more than 128K Datas and loading many times could have been so awesome.

But hey, 464 was the man. :'(

This explain why Speccy and C64 fanboyz tower the CPC as being humble and Lame... >:(
All a CPC needed was 128K and a fast Disk Drive to get well used.

sigh

Quote from: MacDeath on 07:43, 13 December 10

Getting games in more than 128K Datas and loading many times could have been so awesome.


This is EXACTLY what I want to do with this game.
6 more poses to do before I start animating. I think I will animate them all normally first, then go back and see what body parts I can re-use from the frames.

Edit: Did the normal cpc amstrad accept/register 2 button joypads (CPC+ 2 button joypad)? I can't remember....
Edit2: Okay - just read that it can use megadrive pads as long as there is an option for redefine keys to take advantage of the 2 button feature.

MacDeath

#33
Yep because the second button is the Fire button for the second Joystick...


Will your game enable 2player co-op ?


Also your sprite looks quite good, but you have to remember when dealing with a CPC :
Palette is somewhat limited, and the 16 max colours is somewhat limited too.

Try to be sure your character will be quite differenciated from the background...


A character with more 14 colours is awesome, but sometimes when you put it on a background with a lot of details, this can get messy. (was just an example)


Your Sprite : I counted 11 colours only.
this can be quite good as it let you 4 more colours for opponents sprites, and these 4 + 1 colours for the full background.


It would also be quite suitable for a Bad Dudes vs. DragonNinja kind of game...



One of the main problem with the CPC : it has only one Grey.

So many games/graphists could not handle this properly, mixing the grey with odd colours.

sigh

Yes, it will be 2 player which is very important. I want to get the target renegade set up of 6 characters on screen - 2 player characters with 4 enemy characters.

Regarding the backgrounds, they will be detailed but using only 4 colours at the most to make sure that the sprites dont get lost in them.
(So the environment will use the black white, grey and another colour. It will make sense and should look good when I do the mock up:))

MacDeath

Perhaps you use a bit too much blue in your sprite...
If 2 player are to be, they should have quite some difference, Will it be the tshirt ? the Pants ? or simply a completly different design ?

Not every colours on CPC can display an as good gradient as the blue.

Green per example has almost 5 Greens but 4 of them are so similar...


Also remember that sprites are Softwired...getting them too big and too animated can be quite problematic despite having 128K ram...
The CPC has so many things to manage...


BTW good luck in your project.

sigh

With the 2 player mode, I was going to just change the jeans to green as that should be enough to dfferentiate the characters. The enemies, although using the same move set and body parts, will just have a head swap and colour changes (apart from the female enemies). Hopefully, this will save space.

Target renegade is an example of this, with the second player sporting a red shirt instead of an orange one. The enemies have head swaps and different colours:



An example. There are 11 colours in this picture (the sprites are 10). The pixel placement is exactly the same, with the only things being changed are the values of the colour. So for player 2, all mid blue colour from player 1 will now be grey, all light blue colour from player 1 will now be yellow etc.

There are no introduction of new colours. The palette is the same on on each sprite :)





MacDeath

#37
Good, you removed 1 colours (1 of the 4 blues)... and tried two kind of differenciations between both players.

Actually swaped the T-shirt and Pants inks... or used "monochromatic" ful sprites.
This seems good.

One point perhaps : the shadow...
what about simply use a dithering grid of black ?

I put your picture in my Paint.net...the colours are differently set (I used the Theoric values...)

on the one on the left I tried the lack-grid shadow (under the feets).

Of course getting one colour from the shadow to be swapped is also better to differenciate both players... but his may lead to unwanted effects too.



Also tried another way, just for the fun... hope you won't mind.
This is just in case this may help you or give you ideas, not to undermine your great job.

Green and blue.
But those sprites use less colours actually.

Remember that if your background is to be 4colours only (B&W&Grey+1 colours), to use too much the B&W&Grey on your sprite may lead it to mix/blend with the background...

On the other hand if you can free a bit more colours exclusively for the background, you may get the sprites more appart from it.

But it all depends the way you get your game run (the code/program) and/or the way you want it.

sigh

Thank you so much for the shadow idea! The dither shadow looks far better than the solid shadow I did.

The characters work very well against the grey as I made sure that it was one of the key things to get right. The green gradients and blue gradients you used as a test; I was planning on doing those for the enemy characters only as they will represent "gang" colours.
So one enemy might have a red shirt and white jeans, with the other enemy having white shirt with red jeans. This again would be planned out and coloured carefully so that only the values of the colours change and all there would be left to do are head swaps.



Again, the picture above, the body has colour value changes - the head being the only difference which has been swapped. Also these sprites are on the grey background, but because the grey jeans has other colours like the yellow and dark red, it makes the character stand out. (I need to get my LCD colours fixed...).

So I think I'll be using this method as I want the game to run as fast and smooth as possible. I'm thinking that flick screen rather than scrolling would be best.
Regarding the backgroung colurs, I can use more colours higher up on the screen, where I know where the characters will not reach.

MacDeath

Are you planning to use a CPC specs or a PLUS specs ?

on the plus getting split screen/raster interrupt/so on is quite easier, and the 4096 colours choices are also quite interesting...(easier)

But it's a PLUS, not really a CPC (you may not have one...)...

redbox

Quote from: sigh on 17:55, 14 December 10
So I think I'll be using this method as I want the game to run as fast and smooth as possible. I'm thinking that flick screen rather than scrolling would be best.

That's music to any CPC programmer's ears, scrolling is a pain in the ar*e!

It's slightly easier on the Plus, but still a bit of a headache.  I love Plus programming mainly because so little was developed for them and the machine didn't have much of a chance to shine.

But classic CPC programming is the real challenge and what I admire the most  :)

sigh

I used to own a GX4000 but not anymore. I don't really know much about PLUS machines to be honest. My intention was to make use of the CPC 128k as that was very undervalued and squeeze out as much goodness as possible. However, I'm not going to be fussy if someone wants to do it on the PLUS, though I may want to add in extra content to see how much it could be pushed.

sigh

Okay. So far I have done poses for
duck,
grab,
knee,
stun,
hit,
hit into the air,
headbutt,
being held from behind,
being hit while being held from behind
Kicking while being held from behind

I have 6 more poses left to do before I start animating them and producing a mock up. The thing is, I've been catching up on the way sprites are used on the CPC and although this venture is more than possible, I'm a little concerned if I'm doing this the right way. From a programmers point of view, is there anything that you would recommend or I can do to make the programmers life a little easier, or should I just carry on, making the sprites as is and re using as many body parts that I can, as well as making it possible to use careful colouring so that values maybe changed, instead of creating whole new sprites.

What sort of sprite method is would be used for this type of game? From what I've read, it seems like compressed RLE software sprites, but I don't really understand all of it.

In short, I basically need to know what method and the best way for me to tailor the sprites for that method.


MacDeath

#43
Quotebeing held from behind,
being hit while being held from behind
Am I the only one to see sex everywhere ? ::)


BTW... I'm not the most competent on the matter, But I think (it seems logical to me) that if you are to "craft" the sprites from multiple sub-sprites, this use less memory (RAM and Datas...) but shitton more CPU ressource...

Also as you may use software routine to reverse them (left to right...mirror effect) and other routines to recolor them (the inks)... and those are masked too.


Don't forget that if you want to use a 128K config with disk drive, you can easily add loadings between each levels, hence re-fill a new set of Datas.
So get some time to discard useless datas (musics and datas for the other levels... and so on...) and to pre-craft your sprites.

And a +64K can actually mean quite a good lot of Datas for a CPC...


As a result, if "constructing" the sprite is done in real time, this will be a pain for the CPU...

If those are pre-constructed when the game/level loads, you gain place on the disk... (usefull if your game is to be on a limited ROM per exemple...)

A full 320x200 of graphics (160x200 then for a Mode0...) is 16K of datas.
This can be quite a lot of sprites or Tiles...

Concerning tiles, perhaps only a few games 't used a full "screen" of tiles... and most individual levels don't...

16x16 tiles ? 10x12,5 grid of different tiles...rounded to 120 tiles := 16Ko.
Sprites are somewhat bigger but 32-48K may be more than enough to put a lot of them...

48+16 = 64K.
This let you perhaps 16K for the Video Ram and 48K for the codes and sounds and various stuffs.


So many great games actually used only 48K for all those.


Having a 128K config doesn't make an Arcade machine of a CPC.

But this enable to :
-Get more contents...of course.

-use less CPU time : many games were designed to run at 64K Tape config... thery had to decompress Datas when they used them...

exemple : Rick Dangerous : it load once ! the Datas for non actual level are compressed and decompressed as they are used.

This explains a lot : why levels were shorter (half from the 16bit ones), why there are not as many enemies sprites as on other versions (16bit)... no music nor cinematics, and so on.

With 128K (and an Amstrad PLUS) Fano managed to get it to the 16Bit level...

Yet almost no games did this.


As for the mirroring sprites : (getting them from left to right orientation per exemple...) : by "simply" doubling them (in both setting : left and right oriented) you save shirtton of CPU... sort of.



So it is up to you to define what strategy you will use.


You can perhaps compare :

=Double Dragon I

64k :


128K :

                        Ok the graphic could have been better, lol...

Double Dragon II :

64K :


128K :


looks better perhaps...


=ESWAT

128K :


64K :



Those games had 2 versions each : 464 and 6128...
Those are the rare exemple of the actual difference from 64 to 128K.


There is also Final who need a 128K config :



The 128K started to be used at the very end of the CPC carreer... because they had no choices, look at the size of those sprites (the games were a bit sluggish though...)

sigh

This will be a 128k only game with loadings and the images in my pevious post show that the sprite sizes are similar to renegade/target renegade size.

Hmmmm....I though I was being clever by spending a good amount of energy into making sure that crafting sprites would use less RAM not knowing that it would put pressure on the CPU. I think the best thing for me to do is to continue making the sprites by pieces, at least then the programmer can have the option of using pieces, or instruct me to put a pose/frame into a paint package and turn it into a full sprite which would only take a couple of seconds.

That way, the programmer can have more control on whether to use ram or cpu resources for certain animations. (I think... ??? ).

MacDeath

#45
What I told you may not be true, it can depend  on a lot of other factors, mostly the "technological" choices in the code, and the way you manage the Datas, processings and loadings (level design too, gameplay too and so on...)

Remember that it is still an 8bit game.
No need to get 32 completely different opponents  and 512 tiles per levels...

And levels don't necessarily have to be gigantics... each pause between levels is a good occasion to get a new set of stuff (or re-customised stuffs...)
If the game is good, players won't mind the 30 seconds between each levels...
And remember the character's sprites remains the same from levels to levels... the basic sound effects too, and the HUD too (the part to display number of lives, scores and so on...) so you don't have te reload/reconstruct 128K between each levels or sub levels.


Many CPC games used to be slowpoke sluggish...
Oh yeah they could look good on still pictures in magazines, but when you played them, it wasn't that good...

The new tendency on CPC arcade-action games it to get them as smooth and fast as possible.
Play-Ability.

Just look at Dead On Time or StarSabre...


Playability is where it's at.

QuoteI think the best thing for me to do is to continue making the sprites by pieces
still a good way.

Takes less space on Disk perhaps, and also you can always rebuild them completely, it assures the design is good too.

arnoldemu

Quote from: sigh on 02:05, 20 December 10
This will be a 128k only game with loadings and the images in my pevious post show that the sprite sizes are similar to renegade/target renegade size.

Hmmmm....I though I was being clever by spending a good amount of energy into making sure that crafting sprites would use less RAM not knowing that it would put pressure on the CPU. I think the best thing for me to do is to continue making the sprites by pieces, at least then the programmer can have the option of using pieces, or instruct me to put a pose/frame into a paint package and turn it into a full sprite which would only take a couple of seconds.

That way, the programmer can have more control on whether to use ram or cpu resources for certain animations. (I think... ??? ).
Making a game is always a fight between pressure on cpu, or pressure on ram.
Continue as you are doing...

I haven't had time to make those demo programs that I was going to do, I hope in a few days I may be able to do this.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

redbox

Quote from: sigh on 02:05, 20 December 10
Hmmmm....I though I was being clever by spending a good amount of energy into making sure that crafting sprites would use less RAM not knowing that it would put pressure on the CPU.

It all depends really.

If using no compression then recycling sprite parts (arms etc) would be useful.  This would probably be okay on 128kb if there aren't too many characters etc - an easy way to find out is to remember that one screen is 16k in size so in a 128kb game if you you use the the extra 64kb to store graphics you could have 4 uncompressed screens worth.

If using some compression (such as RLE) then recycling sprite parts such as the arm of whatever could be useful, depends on whether the characters compress better as a whole or in parts.

If the programmer wants to store them as a 'delta' on each frame (i.e. you have a key frame for the sprite being usually the first, then store all the next frame as only the 'changes' between them) then recycling parts would be pretty pointless.

I'd just draw them as best you can and then let the programmer worry about how they would squash it all in  ;)

sigh

Quote from: redbox on 17:07, 20 December 10

an easy way to find out is to remember that one screen is 16k in size so in a 128kb game if you you use the the extra 64kb to store graphics you could have 4 uncompressed screens worth.


Could you elaborate on this? If the screen size of the play area is 160x200 - does that represent 16kb? If so, could I just place all the anim and sprites body parts and lay them out on a 160x200 area? I remember working on a mobile phone game where I had to lay out all the animation bits into a certain canvas size, which represented how many parts I could store for each character.

MacDeath

#49
4bits per pixels (4bits = 16 values... hence 16 colours/inks...)

160 pixels per scanlines = 160x4 = 640 bits.
640bits x200 = 128000bits = 128Kb

but in Bytes/octets :
640bits = 80 Bytes
80x200 = 16000 = 16KB.


easy to remember : mode2 is 1 bit per pixel and 640x200...so 640Bitx200 = screen.

The bit flow is the same whatever the Video mode...
This explains why 160x200x16 = 320x200x4 = 640x200x2 = 16KB and represent the same surface on the screen.
and the wide-square-narrow ratios.


The Ram used by the standard screen is from &C000 to &FFFF... it is the fourth 16kB RAM chip... in central/main memory (not extra RAM banks.).

in this RAM bank, the display is as follow :

first KB : displays the first line (upper) of every characters.
2nd KB : second line...
And so on...

This means that to display a character (square 8x8 in mode1 per exemple) :

exemple : first character (upperleft of the screen)

one 8x8 character is 16bits (line) x8.

Each line for the same character is separated by 1KB on the memory map.





Is this that ?

Yesterday I spent the Day with my brother trying to teach me some Assembler concept.
We tried to get WinApe to display something by a direct writing in the RAM bank (Debugger/Assembler...) and found out the lines are sorted as I told.

That was even fun because I had to explain him that the display is done with an interrupt (not a real graphic card on those CPCs...), and tell him the size in memory of the Screen, the resolutions and Bit-per-Pixels and so on...


Also on another sidenote, we couldn't easily find a good CPCwiki page on the matter...


http://www.cpcwiki.eu/imgs/8/8e/Mg_page26.jpg

This for exemple is a scanned book page...

But getting 3 pages on the Memory, RAM and ROM could be great...

Also perhaps creating categories such as...
Essentials ?
Tutorials ?
Base concepts ???

Well stuff like "CPC and Codes for Beginner"...



MacDeath... starting to really learn codes... :'(

Back to topic :
QuoteIf so, could I just place all the anim and sprites body parts and lay them out on a 160x200 area?
It is called a "Sprite sheet" (or tile sheet... or tile map... or whatever...) :laugh:

But as I told you, the CPC don't see this as characters...it is not a character based computer like a Spectrum (Character attribute based).

So for a tutorial purpose/graphical method yes...
This enable you to check how much Data you graphics represent.

But Actually for the code/Computer it is more like a 128000bitsx8 picture, hence a  4000x8pixels (mode0) picture...(totalling 32000 4bit-pixels...)


Of course you, as a Graphist, don't really have to know/use that... but knowing this may ease you collaboration with your Coder (ease his pain...) as you may then give him suitably pre-coded/displayed/well-ordered DATAs...

(Hey Fano, que de souvenirs... ::) )


If you are working on a PC, remember that depending of your graphic application, you may get the wide pixels being managed or not.

on a "normal" graphic utilitary, we often use 2x1 pixels... but Graphix2 manage the square or wide display so 1 pixel is one pixel...


BTW some programs (I often use Paint.net) enable you to reduce the picture with the "close neightbour" (proche voisin) mode, That important or else the application would diter and antialias al the stuff... massacring your 16 colours only picture.

so if all your pixels are well "doubled" you get no artefact and a properly 160x200 sized picture...



Masking the sprites :
This is also important.
To mask a sprite, you can get a second grid in 1 bit per pixel (like a mode2 then) to check wheter it is a displayed pixel or not... the masked part or "transparency effect/colours.

Yet as you use a 16 colours (inks) mode0, it is better to use one inkthat is used on this purpose so yeah, your sprite graphics are 15 colours only (15 displayed inks) but you don't have to get a second set of 1bit coded sprites (the Mask...Spooking !).

Powered by SMFPacks Menu Editor Mod