Quick question on Renegade/Target Renegade graphics

[sigh]

Thanks MacDeath,
 
  I will definitely just continue as is and let the programmer decide on   how they want to use the pieces. It's taking longer this way, but is   probably the best option.
 
  I've now finished full animation of the Grab, knee and headbutt combo.
 
  I'm using paintshop pro for graphics and animations, but I also   downloaded CPC Paint as my lcd isn't displaying the correct colours,   making the amstrad palette a few shades out. I'll get the RGB numbers   from CPC Paint to put it right. Today I'll start planning the walk   cycle.

[redbox]

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 explained it in more detail, but yes you are right - one 160x200 MODE 0 screen is 16kb.  So you can lay out the sprites in this area as a 'sprite sheet'. 

It's also worth doing it for the backgrounds, especially if you're using tiles (which on the CPC are also just sprites really, but it's still best to work in this way as you can recycle lots of bits to make up huge levels) to make up the background.

[MacDeath]

If I remember well Rick Dangerous used a 4x4096 (mode0 pixels) picture for all the Tiles...

This is quite enough for designing 4 levels with quite different flavour, and rick dangerous is awesome looking...


With the multi-loading, you can really get awesome varied backgrounds, and even let yourselfe include a few unique elements (exemple : a statue....) if your animations are not to be too big...


An arena type boss fight (without all those various mook in the way) per exemple can get its own design...)


But of course what you put somewhere you must remove elsewhere...

If you want a shitton of variety in the sprites you may get a bit less detailled backgrounds...

Sprites tend to be a bit bigger and is actually a set of tiles, but often with a lot of unique tiles...
The bigger the sprites, and the more animation frames you get...or the more variety... then more part of the 128K is taken by those.


But well designed tiles can really enable a great array of constructs as those are like LEGO bricks...
And most of time the majority of the background's surface is composed of a few basic texture tiles...

If you want to design your levels, You should try Tiles Studio : it is not the only one of course but it is quite easy to handle and the Tile oriented stuff is just great to compose your stuff...

The good equilibrium between all those is the greatest and hardest achievement because... even with +64K RAM, it remains a poor Z80 doing all the work...

[fano]

Great to see your experience will be usefull for others.You are true , CPC is not a complicated machine but we lack of articles for "total" beginners about CPC architecture.

Two or three little things (sorry about offtopic)

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

It is 2048 bytes (2K).It is often named "blocks".

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...

Not exactly , the CRTC+GA are used to display graphics like a graphic card.

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).

Beware the CPC is close than Spectrum as you can imagine  (CRTC "see" screen data as char array)

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... )

Yes ,that was fun but not easy 
My point is graphist needs to have a minimal knowledge of the hardware.CPC is not PC so this is needed to do some other work than pixelling (like writting program is not the only task for programmer).Some may not agree with my point but some tasks (like color reducing, adjusting palettes or cropping) are not the job of the programmer.
If i ask for a music , i don't expect a MP3 like when i ask for graphics i do not expect a 24bits RGB.

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.

We already spoke about this , avoid absolutely (evil) programs that work internaly in RGB if you want to avoid theses problems.
About PSP , it is fine for 8bits indexed graphics but some export modules like PNG may remap palette (long time i didn't use it so that may have been fixed on recent version)

[arnoldemu]

MacDeath explained it in more detail, but yes you are right - one 160x200 MODE 0 screen is 16kb.  So you can lay out the sprites in this area as a 'sprite sheet'. 

It's also worth doing it for the backgrounds, especially if you're using tiles (which on the CPC are also just sprites really, but it's still best to work in this way as you can recycle lots of bits to make up huge levels) to make up the background.

Yes, i would say lay them out as a sheet, then both you and the programmer can see how they all work together.
Then the programmer can take the sheet, together with your instructions, and process it to generate the final binary data for the game.

For my games, the source gfx are 16-colour bitmaps. The tiles are put side-by-side in a horizontal strip.
I then use my tools to extract this and convert into binary data for the game.

Sprites are similarly done, where each frame is side by side and each sprite uses the same sized rectangle.
However, for some games, where free ram is a problem, the image can be processed so that the smallest
rectangle that fits the gfx can be used, and the width and height of this is stored. But, that can be done by a build tool.

I think the only time to really know exactly how much ram the sprites take up, is when the gfx have been converted into the final binary data, but making a sprite sheet you can estimate the space.

[MacDeath]

It is 2048 bytes (2K).It is often named "blocks".

Ok... it is 2K instead of 1K...
ok ok ok my bad : 8 vertical pixels in a character... so 16k/8=2k... understood.

Not exactly , the CRTC+GA are used to display graphics like a graphic card.

But there's an intterrupt so the Z80 doesn't address to the Video Ram while it is displayed ?

Beware the CPC is close than Spectrum as you can imagine

Ok, but my point was that the pixels are not exactly displayed in the memory exactly as seen on the screen... well, are they ?

And I know the CPC is quite close to the Speccy.. what a shame... all those speccy ports...

We have to chat a bit one of theses days, so You may explain this to me perhaps betterly...

avoid absolutely (evil) programs that work internaly in RGB if you want to avoid theses problems.

That's why it mlay be good to re-process the pictures/source graphics with...Graphix2 per exemple... once it is properly designed with a more modern stuff.

CPC is not a complicated machine but we lack of articles for "total" beginners about CPC architecture.

Major point...
An illustration of the Memory map with a good display and explanation of the Video RAM would be good...

Also : telling which exact chip on the Board is actually the RAM used for the Video ?

It is good to know where the physical stuff is...


or explaining in details some processthat occur...
Those are not always easy to comprehend if there is no graphic demonstration (I'm a Visual guy...)

a Drawing is sometimes better than 10000 words...


If I recall well, the CPCtech.org files include pages like "run a program on a CPC for noob " and stuff like this...

[fano]

But there's an intterrupt so the Z80 doesn't address to the Video Ram while it is displayed ?

This is not an interrupt in the technical meanning.GA activates /wait pin on Z80 but does not request an interruption.(some infos there : http://www.cpctech.org.uk/docs/instrtim.html)

Ok, but my point was that the pixels are not exactly displayed in the memory as seen on the screen... well, are they ?

this is correct.

We have to chat a bit one of theses days, so You may explain this to me perhaps betterly...

No problemo mate 

An illustration of the Memory map with a good display and explanation of the Video RAM would be good...

About video Ram , you just need to understand one or two thing about the CRTC addressing.

There are a lot of jewels about Hardware on cpcwiki/grimware/cpctech/cpcrulez but that takes time to find them.

[sigh]

Okay. I've created a little test of the sprite sheet at 160x200 and it's looks like the main character animations are going to take up at least 2 of those - uncompressed without them being in pieces (this doesn't include the walk which will be re-used on all the sprites). Every pixel is like gold dust, so having a set rectangle for sprite sizes wont work. For instance, the uppercut takes up quite a bit of vertical space, with the fly kick taking up horizontal on the sprite sheet. I'll definitely have to have some of the frames constructed. I'll try and do it for arms and the head meaning that I'll try and keep the body and legs together. I presume contructing head + arms+body is less cpu stress than head+torso+leg+feet+arm.

The shadow that the characters cast should probably be a composite as well.

I'm thinking that 1 sheet could do for the background and another sheet for enemy sprites. which 4 sheets in total. To be honest - I'm wondering how I'm going to fit these unique bosses in. I could have game load the boss characters and have the player fight them in a different location as I would probably need an extra fight sheet just for the bosses. I would prefer if that didn't have to happen though...
I'm also going to remove the idle stance. It's extra frames for moves to come in and out of that pose - alhough it's fine for the headbutt.

At least the kick only has 2 frames!

[MacDeath]

long time ago I tried to get Bad Dude vs Dragonninja's sprites thanks to WinApe's search graphics option and it looks like your case...
Sprites come in different shapes and there is a lot of re-use of same pieces, but with different colours (legs per exemple...)

The player sprites may be more...more ... as they are always displayed they need more frames or more moves...

But I suppose the villains will get less moves... or more specific martial technics  so this could ease after all.


2 banks of 16K for the character ?is it for both players or for only one player ?
Did you doubled those (left/right) or not ?

Remember that you realisticaly cannot get the same amount of moves as a good old Arcade Doubledragon or the variety of a StreetRage3 (Sega megadrive) with3-4 different player characters.... because CPC is a "poor" 8 bit machine with no Co-processor, not that much memory and... well... all is done by software...

But hey, just design good graphics, and you'll see if this can be done as it is with your coder...
It may be possible to skip a few animation frames.
And yeah, some stuff can be -recontructed when used...


Can't wait to see your sprite sheets.


A construction with Head +Legs+ torso&arms perhaps ?

[sigh]

Here is a construction of full whole sprites on a mode 0 sheet:



Here is a construction of the sprites in pieces:


Here is an example of the headbutt pieces: (The middle two are unique. The rest are composite pieces)



I think what I'll do is split the torso and legs in half. This way, the characters and enemies will all use the same legs. The torso, arms and head will be the only composites. When the sprite sheet is properly done I will be making them face all in one direction. Arnoldemu said that there was a conversion array used for mirroring the sprites in renegade so I would need something similar. This is for the main character - 2 player will be a copy with the colour values changed.
As Redbox said, I wont know how much space they take up until it's converted to the cpc format, but I will definitely need to have all the legs as composites. This is obvious in the other renegade games.

[MacDeath]

This looks good... congratulations.

[redbox]

These look really good!!!

I tried to explain it simply because really the programmer should work to fit all the graphics in, but then again you don't want to have to re-draw anything because they are moaning about the size it etc 

[Gryzor]

Ooooh niceeeeee

[sigh]

Hope everyone is having a wonderful holiday.

I'm still animating the main character in which the walk cycle, being hit animation (double dragon style so his head goes left and right) and falling onto the ground has be done. Today, I think I'll do the back kick as it's only one frame.

I've been investigating about what to do with the backgrounds, as I'm considering that smooth scrolling should be given a try for this game as all the previous renegades have been flick screen (I know I said that flick screen would be best - but the more I think about it...). I read this:

http://www.oldschool-gaming.com/view_article.php?art=map_compression

If smooth screen pixel scrolling were possible, which of these methods would be easier for the programmer to handle to get the desired results and why?

[redbox]

I've been investigating about what to do with the backgrounds, as I'm considering that smooth scrolling should be given a try for this game as all the previous renegades have been flick screen

If smooth screen pixel scrolling were possible, which of these methods would be easier for the programmer to handle to get the desired results and why?

I wouldn't worry too much about this because a Renegade style of game doesn't really have a large playing area (maybe about 8 screens worth maximum?).

If you can design the background in tiles (16x16, or in MODE 0 it would be 8x16 because of the double pixels) and use one screen's worth of tiles (160x200) there would be 125 tiles, or 125 bytes.  125 * 8 screens is only 1000 bytes (or 1k) for the tile-maps.

It's the background graphic tiles you need to worry about, which is why I suggest you stick to one screen's worth (125 * 8x16 tiles) as it will then only come out at 16kb without compression.  Your game could be a multi-load so you could use this for every level you create.

[sigh]

I wouldn't worry too much about this because a Renegade style of game doesn't really have a large playing area (maybe about 8 screens worth maximum?).

If you can design the background in tiles (16x16, or in MODE 0 it would be 8x16 because of the double pixels) and use one screen's worth of tiles (160x200) there would be 125 tiles, or 125 bytes.  125 * 8 screens is only 1000 bytes (or 1k) for the tile-maps.

It's the background graphic tiles you need to worry about, which is why I suggest you stick to one screen's worth (125 * 8x16 tiles) as it will then only come out at 16kb without compression.  Your game could be a multi-load so you could use this for every level you create.

I had a look at the target renegade screens and it flick scrolls 15 times on the 2nd level, but they are not "whole" screens that are being flicked, so your definitely right in that 8 screens is definitely more than enough, along with the multi load aspect of the game. Renegade only flicks 5 screens from beginning to end.

[arnoldemu]

Here I have uploaded some code to show interrupt position and the effect of changing the vertical sync position:

http://www.cpctech.org.uk/source/intpos.asm

In relation to games:

The example shows the position of each interrupt on the CPC.
For games, it is much easier to change the mode or colours at the position of an interrupt because it doesn't waste CPU time waiting for an exact position on the screen.

By changing the vsync position, you can change the relative position of the visible part of the screen and also where the interrupts come. But then you end up with a picture shifted within the monitor display. You can get away with one char or so either up/down from the normal position.

To try this out in Winape:
1. Reset the emulated CPC
2. Open Winape's assembler
3. New assembler file
4. Copy and paste this code from the internet browser window into the assembler window
5. Assemble
6, Go back to emulated CPC and type at the BASIC prompt:

CALL &8000

You will see colours in the border and text.

If I have time I will do another example where you can change the dimensions of the screen (and it will report how much K this takes), and also a better grid or similar so you can measure things more easily on the screen.

[arnoldemu]

http://cpcwiki.eu/forum/index.php/topic,668.new.html#new

Here i posted some more source, it can be used in the same way. This one tries to demonstrate how the screen size and position can be changed and it's relation to the amount of ram used (note if hardware scrolling is used, the amount of ram will always be the same - either 16k or 32k for overscan).

Also note that if you expand the screen a lot, you will see the graphics repeating - you need to "activate overscan" to make it use up to 32k of ram.

For both of these examples, how can I make them better for artists to use?
Should I draw a grid or ruler?

I am thinking of doing an example with a mode split, so you can see how that fits in with the way the cpc works.

Both of these examples are fun to play with and also give a good idea of how the cpc works, and how the cpc screen can be setup for games.

[sigh]

Hello everyone and happy new year!

That's wonderful arnoldemu and I'm going to take a look today as I am going to be animating either the punches or throw (fly kick is done). I actually do still have my CPC464 with the 64k expansion tv and modulator connector - working fine and was found in the back of the wardrobe all wrapped up a few days ago. I honestly didn't realise I still had it. So I will type your code onto the 464.

[sigh]

I just executed those commands using winape (much faster than copying code onto real amstrad ). I was able to move the screen using the cursor keys. Was I supposed to be able to change the height and width of it as well?

[arnoldemu]

I just executed those commands using winape (much faster than copying code onto real amstrad ). I was able to move the screen using the cursor keys. Was I supposed to be able to change the height and width of it as well?

Yes on the second example, hold down shift and use the cursor keys to change height and width.

EDIT: Hold down *CTRL* with cursors.

[sigh]

Yes on the second example, hold down shift and use the cursor keys to change height and width.

EDIT: Hold down *CTRL* with cursors.

Yup! I thought I was going crazy for a minute there.
On the "RAM used approx" if it says "&36B0" is that 36kb? (sorry if the answer to the question is obvious - this area is quite new to me).

Also, I was wondering if data can be loaded from a 3" disk, while the game is playing. (I remember some Amiga games doing this). I seperated some legs of the walk cycle at 5 frames each and laid them out on a mode 0 canvas. I have a feel that it may take up the whole canvas when I add in the fame for knees, head buts, flykick etc.

[arnoldemu]

Yup! I thought I was going crazy for a minute there.
On the "RAM used approx" if it says "&36B0" is that 36kb? (sorry if the answer to the question is obvious - this area is quite new to me).

That value is a hex number. &36b0 is 14000 in decimal. Then /1024 to get K (approx 14K).
  I can change the program to show the amount of K if that helps.
 

Also, I was wondering if data can be loaded from a 3" disk, while the game is playing. (I remember some Amiga games doing this). I seperated some legs of the walk cycle at 5 frames each and laid them out on a mode 0 canvas. I have a feel that it may take up the whole canvas when I add in the fame for knees, head buts, flykick etc.

It isn't possible for the cpc to load while the game is playing. Loading from disc takes all the CPU time and requires very careful timing so this can't be done with a game.
On the Amiga it used DMA and interrupts to load so it could be done very easily with almost no CPU impact.

If the data is small you could load some data while playing but it would have to pause as it loaded the new data in.

Knight Force does something similar, as you approach the side of the screen, the disc motor is turned on, and as you leave the screen it loads new data, but there is a short delay when it does it.  So you could look at this as an example of what is possible. You may find that if it's 128k only you have enough ram free, and so loading is not needed within a level.

[redbox]

It isn't possible for the cpc to load while the game is playing.

Exactly, but the game could be multi-load as we discussed before.

If it's a 128kb game, remember that a 3" disc only holds 178kb (per side).  But you could always use compression and then decompress into the 128kb once the level is loaded and before gameplay starts (so you can make use of fast routines etc).

[sigh]

Just checked out the Knight Force by Xyphoe on youtube and witnessed what happened when you approached the side of the screen - definitely not what I want to see happening. That pause was around 5 seconds. Only way I could see this working is if I wanted to load new data for the bosses in which case the 5 second pause could happen while there is text on screen/speech bubbles between the player character and boss character. The boss character at the time of the speech would just be a still frame while the actual animation data is loading in within that 5 second window. That would help to disguise it.

(Still, no point in me worrying about that now while I still have the main character to complete.)