News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Multi-palette sprites

Started by ssr86, 00:19, 02 December 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ssr86

Multi-palette sprites

Imagine a team-sports game where one team should have red uniforms and the other blue. Or maybe you'd want to have some of the baddies appear in different colors? Or just have some sprites(/letters/digits) appear to flash... One way to obtain this effect would be using a lookup-table for translating each byte of the drawn sprite to a new "reordered" color palette. You could also use a separate set of the same sprites but with changed color usages I present here one other method for this. It's somewhat limited but maybe someone finds it useful nonetheless.

Basically the method could be broken into three steps:

1. store all data for the sprite rotated one bit left (right) - like performing a rlca (rrca) instruction on all its bytes
2. before drawing a byte of the sprite data rotate it using rlca (rrca)
3. have a separate drawing routine for each "palette".

Below I assume using mode 0.

The table shows how the colors change when we rotate data stored in standard form (not pre-rotated):

3-2-1-0  || 2-1-0-3 || 0-3-2-1 || 1-0-3-2
standard || 2x_rlca || 2x_rrca || 4x_rrca = 4x_rlca
    0     ||    0    ||    0    ||    0
    1     ||    2    ||    8    ||    4
    2     ||    4    ||    1    ||    8
    3     ||    6    ||    9    ||    c
    4     ||    8    ||    2    ||    1
    5     ||    a    ||    a    ||    5
    6     ||    c    ||    3    ||    9
    7     ||    e    ||    b    ||    d
    8     ||    1    ||    4    ||    2
    9     ||    3    ||    c    ||    6
    a     ||    5    ||    5    ||    a
    b     ||    7    ||    d    ||    e
    c     ||    9    ||    6    ||    3
    d     ||    b    ||    e    ||    7
    e     ||    d    ||    7    ||    b
    f     ||    f    ||    f    ||    f


Note that color 0 and f are constant for all 4 palettes.
Standard order of color bits in a mode 0 pixel is 3-2-1-0, hence I write 3-2-1-0 to denote the standard palette. Rotating the byte by 2 bits will change the order of the color bits of pixels without repositiong the pixels (as when you rotate the pixelbyte by an odd number of bits).

Why storing the data in pre-rotated form?
The initial rotation allows us to even the drawing times for 2 of the possible palettes - the standard palette [3-2-1-0] and 2x_rlca [2-1-0-3] or 2x_rrca [0-3-2-1] - depending on the direction of the initial rotation of data. Both drawing routines need then just one additional rotation instruction. Although for sprites that wouldn't use palette changes it'd be better to store them normally and have a separate standard drawing routine that doesn't use the additional rotation...

Code for drawing one opaque pixel byte:

;; hl=^sprite_data
;; de=^screen
ld a,(hl)
rlca/rrca
ld (de),a
inc de
inc hl
;; 9 nops per byte


Code for drawing one masked pixel byte:

;; hl=^sprite_data
;; de=^screen
;; bc=^mask_table
ld c,(hl)    ;; get pixel byte and use it as mask_table offset
ld a,(bc)    ;; get mask of the pixel byte
and (hl)    ;; mask it
or c           ;;
rlca/rrca    ;; rotate it
ld (de),a    ;; save to screen
inc de        ;; go to next screen position
inc hl        ;; go to next pixel byte
;; 14 nops per byte


Without the preliminary rotation of data, one routine would need 2 rotations and the other none.
[Note that in the case of routine with one rotation we could also try and use self modyfying code to change all rrca to rlca or vice versa... Although I don't know if this would be worth anything...]
The other two palettes need 3 rotations of each byte, so they're are slower to obtain.

The code for drawing one pixel byte:
;; hl=^sprite_data
;; de=^screen
ld a,(hl)
rlca/rrca
rlca/rrca
rlca/rrca
ld (de),a
inc de
inc hl
;; 11 nops per byte


In other words:
There are 4 such "palettes" in mode 0 (2 in mode 1) but only 2 can be obtained with just 1 additional instruction (rlca/rrca) in the pixel-byte drawing code. The other two would need adding three rotation instructions to the drawing code. Of course if we would have only one set of sprites (say the player character) that is unique to the game (that is no other character in the game uses his data) then we could use one separate routine that rotates each byte of the sprite data buffer by 2 bits for changing his palette permanently... Repeating this operation four times would return the sprite to its standard palette.

Such routine would run the code below for each byte of the sprite data:
;; hl=^sprite_data
ld a,(hl)    ;; get sprite data
rlca/rrca    ;; rotate 1 bit
rlca/rrca    ;; rotate 1 bit
ld (hl),a    ;; save sprite data
inc hl
;; 8 nops per byte


-----------------------------------------------------------------------------------------------------
The method is also applicable to dual-playfield mode 0*. However there are some additional restrictions:
- you can use 2 palettes - the 3-2-1-0 and 2-1-0-3 or 0-3-2-1 (once again - depending on the direction of the initial rotaion of data)... but maybe you can find other "good choices" like the ones below
- if you use 3-2-1-0 and 2-1-0-3 palettes then you have to use colors 5, e, f for the sprite data. Then they won't change into one of the background colors (0, 4, 8, c) or ending with less sprite colors (e.g. c1 -> c2, c2 ->c2, c3-> c3); here we will have 5->a [c1->c2], e->d [c2->c1] and f->f [c3->c3]
- if you use 3-2-1-0 and 0-3-2-1 palettes then you have to use colors a, d, f for the sprite data; here we will have a->5 [c2->c1], d->e [c1->c2] and f->f [c3->c3] 
- use 0 as the sprite's transparent color

The pixel drawing code becomes:
;; de=^sprite_data
;; hl=^screen
ld a,(de)    ;; get sprite data byte
rlca/rrca    ;; rotate it
or (hl)        ;; or with background
ld (hl),a    ;; save to screen
inc hl        ;; go to next screen position
inc de        ;; go to next sprite byte
;; 11 nops per byte


*) for "dual-playfield mode 0" we set the mode 0 palette in accordance with the points below:
- colors 0, 4, 8, 12 are background ink colors and can be chosen freely
- colors 1, 2 ,3 , 5, 6, 7, 9, a, b, d, e, f are used for sprite inks but we set c1=c5=c9=c13, c2=c6=c10=c14 and c3=c7=c11=c15; so the sprite can only have 3 different colors + 1 color for transparency


This method can also be used with mode 1 but then you have only two palettes that don't reposition the pixels in the byte.

---------------------------------------------------------------------------------------------------------
Other possible usage:

This method allows "color-flashing" of a sprite. This could be achieved in three ways:
1. Adding a separate routine that would rotate every byte of the sprite data (the sprite's buffer). After four calls the sprite would

return to its normal palette.
2. Similar to the above but this time we want the subroutine to rotate the screen data where the sprite was drawn. This assumes that you are not redrawing the sprite during the flashing (because you would erase the effect). Also you can't touch the bytes that where masked or skipped during drawing of the sprite because you would corrupt the background.
I think this method should be useful if you wanted to make the time or score display flashing. If the timer would be redrawn once per second then you could rotate the screen data bytes where the digits were drawn - if the digits were not masked... Although I think that it is possible to modificate the routine for masked sprites - you would have to skip rotating the transparent bytes of the sprite and for the masked bytes you would have to mask them again to obtain the part of the byte which belongs to the sprite, rotate that and combine it with the background part of the byte...
3. Having all 4 drawing subroutines and drawing the sprite using a different routine every time. 

---------------------------------------------------------------------------------------------------------
Was this approach already used somewhere before?


Comparison to the other two approaches (that I could think of):
1. using lookup table
- with the presented method you don't need lookup tables so you save some memory (each table would take 256 bytes and you need at least one)
- both methods would need a separate routine for each palette, although with lookup tables you could actually get away with just one routine by changing the pointer to the color conversion table before each call
- lookup tables allow more freedom with the palette choices (only four restricted palettes for the presented method and you have to choose your initial palette wisely)
- using lookup tables is slower

2. one set of sprites for each palette
- would be the fastest approach but the memory cost would be just too expensive for heavily animated objects

Other disadvantages:
- can't use ldi for drawing opaque bytes

sigh

#1
I'll need to re-read your post in greater detail during lunchtime, but here is a method that Axelay described to me, for what I could do for the football game I am making. The players in my game will have different skin colours on the same team:

Football Fever (aka - Games with smooth "1" pixel multi directional scrolling.)

It on page 15 and I have drawn graphical examples of how it could work.

arnoldemu

@ssr86:

I normally use the lookup table method. The same method, as you say, can be used to make the sprite flash white by using a different table.

I never considered the rlca, rrca method. Nice idea. I don't think I've seen that used before.

Axelay's method is a form of compiled sprite I think, because he talks about storing some data in registers. So this means draw some using normal draw methods and some with register data.

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

ssr86

#3
Quote from: sigh on 01:44, 02 December 14
I'll need to re-read your post in greater detail during lunchtime, but here is a method that Axelay described to me, for what I could do

for the football game I am making. The players in my game will have different skin colours on the same team:

Football Fever (aka - Games with smooth "1" pixel multi directional scrolling.)

It on page 15 and I have drawn graphical examples of how it could work.

It gave me another idea: instead of bit rotations we could or/and eventually xor. This method would be have equal execution times for all possible palettes. It won't be faster than the rlca/rrca method as we also add one additional instruction to the code for drawing a byte of the sprite data. If we have a free register that we can use to load the value to use for the additional logical operation then the time would be the same as for the rotation method. If we don't have a spare register to use then we would have to use the more expensive or/and/xor value which would add an additional nop for each byte...
Also note that the resulting palettes for or/and won't have 16 different colors... however all xor palettes for are 16 color.

If we were drawing masked sprites then we have to choose the x such that the color used for transparency will stay unchanged... But maybe I'm wrong here...

The only rule is that the or/and byte value has to be of the form xxyyzztt (that is if you don't want to end up with a different palette for the right pixels and left pixels).
So there are 16 possibilities for each logical operation, but many of them are not very useful...

In the table below I list all the possible reorderings:
(x[=x3-x2-x1-x0] means that the used value is %x3-x3-x2-x2-x1-x1-x0-x0)

  x    color     ORx      ANDx     XORx
                [id]      [1]      [id]
0000  0-1-2-3  0-1-2-3  0-0-0-0  0-1-2-3
      4-5-6-7  4-5-6-7  0-0-0-0  4-5-6-7
      8-9-a-b  8-9-a-b  0-0-0-0  8-9-a-b
      c-d-e-f  c-d-e-f  0-0-0-0  c-d-e-f

                 [8]      [2]      [16]
0001  0-1-2-3  1-1-3-3  0-1-0-1  1-0-2-3 
      4-5-6-7  5-5-7-7  0-1-0-1  5-4-7-6
      8-9-a-b  9-9-b-b  0-1-0-1  9-8-b-a
      c-d-e-f  d-d-f-f  0-1-0-1  d-c-f-e

                 [8]      [2]      [16]
0010  0-1-2-3  2-3-2-3  0-0-2-2  2-3-0-1
      4-5-6-7  6-7-6-7  0-0-2-2  6-7-4-5
      8-9-a-b  a-b-a-b  0-0-2-2  a-b-8-9
      c-d-e-f  e-f-e-f  0-0-2-2  e-f-c-d

                 [4]      [4]      [16]
0011  0-1-2-3  3-3-3-3  0-1-2-3  3-2-1-0
      4-5-6-7  7-7-7-7  0-1-2-3  7-6-5-4
      8-9-a-b  b-b-b-b  0-1-2-3  b-a-9-8
      c-d-e-f  f-f-f-f  0-1-2-3  f-e-d-c

                 [8]      [2]      [16]
0100  0-1-2-3  4-5-6-7  0-0-0-0  4-5-6-7
      4-5-6-7  4-5-6-7  4-4-4-4  0-1-2-3
      8-9-a-b  c-d-e-f  0-0-0-0  c-d-e-f
      c-d-e-f  c-d-e-f  4-4-4-4  8-9-a-b

                 [4]      [4]      [16]
0101  0-1-2-3  5-5-7-7  0-1-0-1  5-4-7-6
      4-5-6-7  5-5-7-7  4-5-4-5  1-0-3-2
      8-9-a-b  d-d-e-e  0-1-0-1  d-c-f-e
      c-d-e-f  d-d-e-e  4-5-4-5  9-8-d-c

                 [4]      [4]      [16]
0110  0-1-2-3  6-7-6-7  0-0-2-2  6-7-4-5
      4-5-6-7  6-7-6-7  4-4-6-6  2-3-0-1
      8-9-a-b  e-f-e-f  0-0-2-2  e-f-c-d
      c-d-e-f  e-f-e-f  4-4-6-6  a-b-8-9

                 [2]      [8]      [16]
0111  0-1-2-3  7-7-7-7  0-1-2-3  7-6-5-4
      4-5-6-7  7-7-7-7  4-5-6-7  3-2-1-0
      8-9-a-b  f-f-f-f  0-1-2-3  f-e-d-c
      c-d-e-f  f-f-f-f  4-5-6-7  7-6-5-4

                 [8]      [2]      [16]
1000  0-1-2-3  8-9-a-b  0-0-0-0  8-9-a-b
      4-5-6-7  c-d-e-f  0-0-0-0  c-d-e-f
      8-9-a-b  8-9-a-b  8-8-8-8  0-1-2-3
      c-d-e-f  c-d-e-f  8-8-8-8  4-5-6-7

                 [4]      [4]      [16]
1001  0-1-2-3  9-9-b-b  0-1-0-1  9-8-b-a
      4-5-6-7  d-d-f-f  0-1-0-1  d-c-e-f
      8-9-a-b  9-9-b-b  8-9-8-9  1-0-2-3
      c-d-e-f  d-d-f-f  8-9-8-9  5-4-6-7

                 [4]      [4]      [16]
1010  0-1-2-3  a-b-a-b  0-0-2-2  a-b-8-9
      4-5-6-7  e-f-e-f  0-0-2-2  e-f-c-d
      8-9-a-b  a-b-a-b  8-8-a-a  2-3-0-1
      c-d-e-f  e-f-e-f  8-8-a-a  a-b-8-9

                 [2]      [8]      [16]
1011  0-1-2-3  b-b-b-b  0-1-2-3  b-a-9-8
      4-5-6-7  f-f-f-f  0-1-2-3  f-e-d-c
      8-9-a-b  b-b-b-b  8-9-a-b  7-6-5-4
      c-d-e-f  f-f-f-f  8-9-a-b  3-2-1-0

                 [4]      [4]      [16]
1100  0-1-2-3  c-d-e-f  0-0-0-0  c-d-e-f
      4-5-6-7  c-d-e-f  4-4-4-4  8-9-a-b
      8-9-a-b  c-d-e-f  8-8-8-8  4-5-6-7
      c-d-e-f  c-d-e-f  c-c-c-c  0-1-2-3

                 [2]      [8]      [16]
1101  0-1-2-3  d-d-f-f  0-1-0-1  d-c-f-e
      4-5-6-7  d-d-f-f  4-5-4-5  9-8-b-a
      8-9-a-b  d-d-f-f  8-9-8-9  5-4-7-6
      c-d-e-f  d-d-f-f  c-d-c-d  1-0-3-2

                 [2]      [8]      [16]
1110  0-1-2-3  e-f-e-f  0-0-2-2  e-f-c-d
      4-5-6-7  e-f-e-f  4-4-6-6  a-b-8-9
      8-9-a-b  e-f-e-f  8-8-a-a  6-7-4-5
      c-d-e-f  e-f-e-f  c-c-e-e  2-3-0-1

                 [1]      [id]     [16]
1111  0-1-2-3  f-f-f-f  0-1-2-3  f-e-d-c
      4-5-6-7  f-f-f-f  4-5-6-7  b-a-9-8
      8-9-a-b  f-f-f-f  8-9-a-b  7-6-5-4
      c-d-e-f  f-f-f-f  c-d-e-f  3-2-1-0


If you could use a register for the value for or/and/xor then changing palette would only require changing it's value before calling the drawing routine. If you can't do that then you would have to write a separate routine for each palette or use self-modyfing code to replace all the values in the loop.

EDIT: I rewrote the post

sigh

Any further updates on this? The football game I'm making would find this useful.

ssr86

#5
Maybe one observation regarding the and/or method:

If you use colors 0, 3, 5, 6, 9, a, c, f for your sprite's colors.

0-+-+-3
+-5-6-+
+-9-a-+
c-+-+-f


Let's denote such "standard" sprite palette as 0-3-5-6-9-a-c-f
Then looking at the "and palette" table (if you want color 0 to stay put - good if you want to use it for transparency and masking)
You get four 8-color sprite-palette reorderings that may be useful.

For "and" these are (x and the resulting sprite palette):
0111 : 0-3-5-6-1-2-4-7
1011 : 0-3-1-2-9-a-8-b
1101 : 0-1-5-4-9-8-c-d
1111 : 0-3-5-6-9-a-c-f (id)
And maybe someone can find more useful combinations.
Note that the second color (actually - the third and fifth too) is different in only one palette - this could be used as skin color for example...I think...

The palettes created with xor are permutations, so no color stays in place... I guess that without repeating some colors in the set palette these "palette reorderings" won't be very useful for in-game sprites

MacDeath

#6
Software palette swap was actually quite often used.
most of time it was when graphics were stored in other video mdoes.

Example :
= Antiriad : graphics are in 2bit per pixels (mode1) but converted into 4bpp (mode0) with having to chose one of the 4x4 palette...
the game's palette is divided into 4 different 4 colour palettes, with redundant black most often.
often used to port graphics from C64 actually.

=Barbarian : somewhat same for fighter sprites, stored in 2bpp (mode1) then while one fighter sticks to grey+pink+black+transparency, the adversary would use reserved colours that would then change for each opponent

=Many speccyported games would as well turn 1bpp (speccy/mode2) graphics into Mode1 (2bpp) yet in 2 colours only : transparency+colour... or into 1bpp colours (= two colours)+1bpp mask (transparency).
Some speccy ports would have the sprites turned into coloured ones with no Attribute clashes.

Firetrap is quite an example I guess.


Not sure if to go full Mode0 but trying with more colours wouldn't use too much precious CPU ?Is this supposed to be done at each frame or precalculated then just would use more RAM to store the modified graphics ?
Could have been a point to have a GX4000 with 128k RAM... would enable such method for precalculated colour swaps for the datas/tiles/sprites from the cartridge. (also good for pre-shifted sprites)

andycadley

Quote from: MacDeath on 22:48, 07 December 14Not sure if to go full Mode0 but trying with more colours wouldn't use too much precious CPU ?Is this supposed to be done at each frame or precalculated then just would use more RAM to store the modified graphics ?
Could have been a point to have a GX4000 with 128k RAM... would enable such method for precalculated colour swaps for the datas/tiles/sprites from the cartridge. (also good for pre-shifted sprites)
I doubt CPU is really an issue, most of the attempts to palette swap like this come from either porting Speccy (2 colour) or C64 (3 colour) sprites to Modes 1 and 2 respectively. It's more about making it easier to drag graphics from other machines easier than any real kind of saving. If anything it would be an attempt to save memory, but it's difficult to do effectively without compromising graphical quality. I think you'd have to have a lot of animation frames to really be worth it.

The GX certainly didn't need extra RAM, it has more than enough to do this kind of thing without even putting pressure on the machine at all. Like all consoles, it's RAM requirements are much, much less than a general purpose computer so 64K is actually pretty generous.

MacDeath

#8
A bit out of topic but... GX4000 is a 464PLUS with only cartridge.
being a "CPC" the 64K may be used for "pseudo VRAM" purpose.

You double-buffer ? 32K are used.
Have full screen double buffering ? damn that's now 48 to 64K somewhat used.

considering standard sized screen... (256x256 or 320x200, sort of) of 16K in double buffering.
I guess 32K free RAM is more than enough then, but as cartridge ROM is expensive, you can gain on the data stored, be it re-colouring stuffs, decompress datas, sound samples, have the sprites flipped (upward/downward or left-right) or even other things.

Can make sense as a simple sprite-set can then be turned into both direction and with different colours or mixings or flavours.
But yeah, GX4000 wasn't actually meant to be ambitious at all so 64K is fearly enough for what it is actually.
With a better hardSprite system able to go DMA-use things in the extraRAM,  128K RAM could really have been used well as a way to have bigger games in smaller ROMs and the console would have been quite better.

Software recolouring is some sort of procedural graphic after all.  :laugh:


Concerning Games like Antiriad, the "palette swaps" also apply to background tiles. In this respect it was a brilliant C64 port indeed.
And to use this is not small bizness when you deal with 64K machines versions.
Graphic Datas in native CPC mode can really go quite big to store compaired to Speccy or C64.

the quite big spritesheet from barbarian actually weights half as if stored in native Mode0 (4bpp) because it is stored in "mode1" (2bpp).
For a CPC464 with 16K used by Video and multiloads taking 10 minutes, 48K is not that plentifull.
remember Barbarian's background are in native CPC graphics... bam, 16K.

Good point those games had no scrolling so easier to handle software palette swap and 2bpp to 4bpp conversion in real time.


Anyway to have a good palette swap system for bigger stuffs could be nice.
Just a questions : could then the graphics be stored in a more exotic format so to have them stored in 3bpp (3bits per pixels = 8 colours) then converted into 8 inks (7 colours + tranparency or just 8 colours if background tiles) for  mode0 ?




(I suck at coding so couldn't figure it out)

arnoldemu

The 64KB in the GX4000 is not a bad thing if you use more cartridge ROM.

A 64KB GX4000 with 128KB rom is comparable to a 128KB ram machine without cartridge.

The ROM is the same speed as RAM to access, so in theory you can put all the data you would put into the 128KB ram into ROM.

The GX4000 game would need a different memory map and instead of doing:

LD BC,&7FC4
OUT (C),C

you do

LD BC,&DF83
OUT (C),C

that's the idea anyway.

The problem is self modifying code, because in ROM it can't be changed  :laugh:
And of course if you need some variables you need them in RAM, so you need a small space for those variables.

But of course, if you are using compiled sprites, you can put the code in ROM and just execute it :)

So GX4000 is not so nasty.


In fact, I find playing games on GX4000 really nice. If the game works through joypads throughout it's a nice fun way to play.
Quick start up, straight into the game, play for a bit. It feels different to sitting at a computer using keyboard.

Almost like an Amstrad XBOX  :laugh:

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

TFM

Quote from: arnoldemu on 14:20, 08 December 14
A 64KB GX4000 with 128KB rom is comparable to a 128KB ram machine without cartridge.

A 128 KB machine can load from disc / hard disc and become unlimited that way. While a 128 KB Cart is limited to 128 KB.

Quote from: arnoldemu on 14:20, 08 December 14The GX4000 game would need a different memory map and instead of doing:

LD BC,&7FC4
OUT (C),C

you do

LD BC,&DF83
OUT (C),C

that's the idea anyway.

Well &7FC4 targets &4000-&7FFF; in contrast &DF83 targets &C000-&FFFF. A problem when accessing MM-features (in the first case) or when accessing V-RAM (in the second case).

I agree, the GX4000 is a nice machine and provides all needed. BUT - big BUT, the games need to be made for it.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

arnoldemu

I think you just don't like the gx4000.

More correct on what I am saying: A 128KB game (all 128KB is loaded with no furthur loading) can be done on gx4000 if it was reprogrammed to use cartridge pages. Yes you would need to change the location of the screen. So GX4000 doesn't need to run just "64KB" only games, it is like a 128KB machine if you use the cart rom well.

I don't see a problem accessing v-ram. V-ram doesn't need to be at &c000. Why can't it be at &0000 or &4000 or &8000?
So there is no problem here.

I don't see problems at all. I compare them and say they can do the same. 64KB GX4000 is not bad!

Think 64KB *work* ram, with 512KB storage, but here storage is instant.

Loading from disc, harddisc is not instant.


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

TFM

#12
Quote from: TFM on 18:29, 08 December 14I agree, the GX4000 is a nice machine and provides all needed. BUT - big BUT, the games need to be made for it.
Quote from: arnoldemu on 18:42, 08 December 14
I think you just don't like the gx4000.

?? I mean what I say.  :)


Quote from: arnoldemu on 18:42, 08 December 14More correct on what I am saying: A 128KB game (all 128KB is loaded with no furthur loading) can be done on gx4000 if it was reprogrammed to use cartridge pages. Yes you would need to change the location of the screen. So GX4000 doesn't need to run just "64KB" only games, it is like a 128KB machine if you use the cart rom well.
Same is true for 512 KB games, when using a 512 KB Cartridge.

Quote from: arnoldemu on 18:42, 08 December 14I don't see a problem accessing v-ram. V-ram doesn't need to be at &c000. Why can't it be at &0000 or &4000 or &8000?

&0000 - Interrupts!

&4000 - memory mapped groups
&8000 - the ONLY common area, so good for the stack


TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

andycadley

Quote from: TFM on 18:29, 08 December 14

A 128 KB machine can load from disc / hard disc and become unlimited that way. While a 128 KB Cart is limited to 128 KB.


But there's still only about 180K on a 3" floppy, so it's not that big a difference. Unless you start moving to multi-disk games, but you can count the number of those that exist on one hand and still have fingers to spare.
Quote from: TFM on 18:29, 08 December 14
Well &7FC4 targets &4000-&7FFF; in contrast &DF83 targets &C000-&FFFF. A problem when accessing MM-features (in the first case) or when accessing V-RAM (in the second case).

I agree, the GX4000 is a nice machine and provides all needed. BUT - big BUT, the games need to be made for it.[/font]
Accessing V-Ram isn't really an issue, since you can write-through anyway. Or relocate it to elsewhere. Or page the ROM lower with RMR2.

TFM

RMR2 is of course the solution.  8)  But not &DF03 or so.  :)


But V-RAM needs go be accessed if you want to use masks for sprites or similar.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

arnoldemu

Im 2. Interrupts running from Rom. I have done that before. Using rmr 2 limits to 128k Rom.

Anyway, I will make some examples. Sorry, I went off topic.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

andycadley

Quote from: TFM on 19:36, 08 December 14
But V-RAM needs go be accessed if you want to use masks for sprites or similar.
Not necessarily, a lot of sprite routines mask as part of redrawing the background, it's less flickery than trying to draw the background and then mask sprites over the top of it.

TFM

Quote from: arnoldemu on 20:04, 08 December 14
Im 2. Interrupts running from Rom. I have done that before. Using rmr 2 limits to 128k Rom.

Anyway, I will make some examples. Sorry, I went off topic.


Me sorry too... For Video relevant stuff use RMR2 for anything else you can still use the rest of the 512 KB.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: andycadley on 20:04, 08 December 14
Not necessarily, a lot of sprite routines mask as part of redrawing the background, it's less flickery than trying to draw the background and then mask sprites over the top of it.


Works only for single colored background, not for background that is like a picture.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

andycadley

Quote from: TFM on 22:40, 08 December 14

Works only for single colored background, not for background that is like a picture.
No, works for any kind of background, it's just a matter of careful composition. Tends to work better if you can't have too many overlapping sprites (such as in many shoot-em-ups) or if you can't double-buffer the display (because then it helps massively with avoiding flicker).

TFM

Guess I see the point you're driving at. Well, as you told, it depends on the game itself.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

ssr86

#21
Quote from: TFM on 22:40, 08 December 14
Quote from: andycadley on 20:04, 08 December 14
Not necessarily, a lot of sprite routines mask as part of redrawing the background, it's less flickery than trying to draw the background and then mask sprites over the top of it.
Works only for single colored background, not for background that is like a picture.


Well the dual playfield mode 0 is one example of using such routine and it's using 4 colors for background...

TFM

It does NOT help if you have sacrifice another 16 KB block!  :laugh:
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Gryzor

I only came here for the pictures, this was boring.

Powered by SMFPacks Menu Editor Mod