Started by sigh, 18:17, 07 December 10
0 Members and 1 Guest are viewing this topic.
Quote from: sigh on 19:44, 20 December 10Could 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.
Quote from: MacDeath on 07:15, 21 December 10Each line for the same character is separated by 1KB on the memory map.
Quote from: MacDeath on 07:15, 21 December 10That 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...
Quote from: MacDeath on 07:15, 21 December 10But 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).
Quote from: MacDeath on 07:15, 21 December 10Of 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... )
Quote from: MacDeath on 07:15, 21 December 10BTW 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.
Quote from: redbox on 16:31, 21 December 10MacDeath 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.
QuoteIt is 2048 bytes (2K).It is often named "blocks".
QuoteNot exactly , the CRTC+GA are used to display graphics like a graphic card.
QuoteBeware the CPC is close than Spectrum as you can imagine
Quoteavoid absolutely (evil) programs that work internaly in RGB if you want to avoid theses problems.
QuoteCPC is not a complicated machine but we lack of articles for "total" beginners about CPC architecture.
Quote from: MacDeath on 19:33, 21 December 10But there's an intterrupt so the Z80 doesn't address to the Video Ram while it is displayed ?
Quote from: MacDeath on 19:33, 21 December 10Ok, but my point was that the pixels are not exactly displayed in the memory as seen on the screen... well, are they ?
Quote from: MacDeath on 19:33, 21 December 10We have to chat a bit one of theses days, so You may explain this to me perhaps betterly...
Quote from: MacDeath on 19:33, 21 December 10An illustration of the Memory map with a good display and explanation of the Video RAM would be good...
Quote from: sigh on 14:56, 28 December 10I'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 screenIf 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?
Quote from: redbox on 16:20, 28 December 10I 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.
Quote from: sigh on 15:31, 01 January 11I 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?
Quote from: arnoldemu on 22:58, 01 January 11Yes on the second example, hold down shift and use the cursor keys to change height and width.EDIT: Hold down *CTRL* with cursors.
Quote from: sigh on 16:30, 02 January 11Yup! 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).
Quote from: sigh on 16:30, 02 January 11Also, 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.
Quote from: arnoldemu on 16:38, 02 January 11It isn't possible for the cpc to load while the game is playing.
Page created in 0.116 seconds with 50 queries.