Karoshi MSX Community
08 de Diciembre de 2019, 07:01:53 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: 1 ... 4 5 [6]
  Imprimir  
Autor Tema: What about the remake of Ghost'n'Goblins?  (Leído 60092 veces)
0 Usuarios y 1 Visitante están viendo este tema.
dvik
Karoshi Fan
**
Mensajes: 80


WWW Email
« Respuesta #75 : 11 de Noviembre de 2007, 07:20:02 pm »

Hi SEPPASEPPA,

I beleive that Malaika does something similar. The GnG demo is scrolling less than 128 already and this is not a problem, especially if the game can use a 128kB or 256kB megarom. then the tiles can switch to a new set of tiles half way through a level without affecting performance.

If you send your demo I'll send you something in return. But its too early to share that here on the forum but I'm sure you are interested in it.
En línea
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #76 : 11 de Noviembre de 2007, 09:00:57 pm »

dvik: Malaika does not change patterns or color definitions during ingame stage, as every possibilities for each tile are pregenerated and preloaded to VRAM pattern and color definition before the stage starts, independly for each bank, in order to use different "tilesets" in different banks at the same time. At Malaika, just the name table and the sprite atribute data is transferred during the ingame... this way every time I make a transfer to vram I transfer the same amount of data no matter the frame.

Your GnG approach can't work that way, as you have lots of more tiles out there: so I guess you redefine patterns while the ingame, and at each 8 frames you really scroll the name table too. What I can't imagine is how you can transfer that much data into the vram every frame: and moreover, how don't you get a slower frame each 8 frames, because of transferring the name table definition each 8 times?  Huh, and how you still have room for the game and enemy logic for every frame?. Man, your code should be really efficient in order to work that way! :god:
En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
dvik
Karoshi Fan
**
Mensajes: 80


WWW Email
« Respuesta #77 : 11 de Noviembre de 2007, 09:24:29 pm »

Ah yes, I forgot that Malaika uses 4 pre-programmed sets of 64 tiles and then updates the bgmap to do a smooth2-pixel scroller, right?

The more of the cpu that goes to the scroll engine the fewer are left for game logic. The GnG demo has enough cpu cycles left to do the game I think. It has decent movement, sound and some super basic enemy ai and still has around 20-25% cpu left. If thats enough for full enemy ai and game logic, I'm not sure.

Updating the bgmap every 8 pixels is very easy, I just don't do as much game logic that frame Smiley I think the only thing I do in the demo during that frame is playing music and running the sprite engine. But dedicating 1/8 of the frame to this won't be visible to the gamer.
En línea
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #78 : 11 de Noviembre de 2007, 09:28:47 pm »

Ah yes, I forgot that Malaika uses 4 pre-programmed sets of 64 tiles and then updates the bgmap to do a smooth2-pixel scroller, right?

Actually, 8 pre-programmed sets of 32 tiles for a smooth1-pixel scroller. The thing is that each bank has an independant definition, that's why there are more than 32 tiles there (for example, those tiles being a cloud in the upper banks are the green grass at the bottom bank). Remember that this is not a mixed mode, but normal SCREEN2, so I have independant bank definition for my tricks' pleasures Wink
« Última modificación: 11 de Noviembre de 2007, 10:11:46 pm por Viejo_archivero » En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
mäsäxi
Karoshi Lover
***
Mensajes: 121



Email
« Respuesta #79 : 16 de Octubre de 2008, 09:54:49 am »

I hope I can give new life to this Ghost´n´Goblins project. Smiley

What is today´s situation for MSX G´n´G?

I surely hope you still like to finish your game, as your scrolling demos two years ago were REALLY IMPRESSIVE!!!!!!!! Something NEVER SEEN BEFORE on MSX-1!!!!!!!! Smiley

Please please please please please please please please continue programming Ghost´n´Goblins!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Smiley

(and ask matra to put it into cartridge form!:D)
En línea
SEPPASEPPA
Karoshi Newbie
*
Mensajes: 24


Email
« Respuesta #80 : 27 de Noviembre de 2008, 07:24:13 pm »

Veijo, does, your original concept about GNG , use screen 2 or as dvik one are you using a hybrid mode?
En línea
Jon_Cortazar
Administrator
Karoshi Forum's God
********
Mensajes: 2777



WWW Email
« Respuesta #81 : 27 de Noviembre de 2008, 09:58:52 pm »

My initial scrolling concept demo was an early implementation of Malaika's engine and, as Malaika, it uses a pure 3-banks Screen 2 mode: the basis is to have all tile possibilites predefined in the tile table and just change the name table. Dvik's implementation was far better and afair it was based on real-time tile redefinition, a different approach from mine: as he needed to redefine tiles, a single bank mode was really a must for avoiding 3x transfers.
En línea

Jon Cortázar Abraido (aka El Viejo Archivero)
RELEVO Videogames
[Dioniso: La cafeína está haciendo su trabajo; yo espero hacer el mío.]
[pitpan: Me sigue pareciendo más productivo jugar al SNAIL MAZE que seguir esta discusión.]
SEPPASEPPA
Karoshi Newbie
*
Mensajes: 24


Email
« Respuesta #82 : 28 de Noviembre de 2008, 10:53:32 am »

My initial scrolling concept demo was an early implementation of Malaika's engine and, as Malaika,3x transfers.

OK, i've done some experiments about scrolling. Let's me explain.
I start with pure screen 2 and i have all the tiles loaded, changing only the name table.
I start in the leftmost position say, x=0 (charater position,not pixel position)
Every 8 pixels scroll (my example is only forward scrolling but can be adapted), i reload the same table as in position x=0, only shifted 1 char left. Plus i redefine the changing tiles (because of the scroll the in-going tiles from right maybe are new shapes).
With the dvik patterns i've found that during scrolling only 1 to 5 tiles must be redefined, and some tiles became unused because they go out of screen.

The point is that instead of redefine 100 char tiles, i only redefine the new tiles that are from right to left.
In the worst case an entire column of tiles (24) need to be redefined, however pratice showed me that only 5 tiles can vary between physical name table scrolls.


The z80 have all the info to quicly modify only the tiles needed, because the work of determine witch tiles change is done on a PC that takes a full map bitmap image, scan this and generate tiles info.
Thus every name table scroll, the z80 overwrite the unused tiles patterns and colors with the new from right, and do also the name table scroll

There is an advantage:
You do not need to keep all the tiles of an entire map to a maximum of 64 different tiles. Only at a specific x charater value you are costrained to 64 tiles. when the screen scroll, new incoming tiles (24) will substitute the tiles that are unused.
Of course the n. of tiles on every screen *must be* less or equal to 64, but the number of tiles in the global map is unlimited.

Pratically, during scrolling, when a tile is unused, is replaced by a new tile that comes on screen because of the scroll.
In my example, because of the limited amount of tiles involved i also change colors, not only patterns.

There is a diadvantage:
When designing the map you must ensure that the number of different tiles never exceed 64.
For example if you use all 64 tiles at x=0 and for x=1 you have 3 tiles that become unused and 5 that became new, you end up with 64 - 3 + 5 =66 tiles. Not good. However this was (with dvik tiles) never happened.





En línea
ARTRAG
Visitante
« Respuesta #83 : 28 de Noviembre de 2008, 07:32:01 pm »

I did not fully understand you idea.

Each new 8x8 object that enter on the screen needs up to 2 tiles shifted in 8 positions, i.e. 16 tiles (actually 15).
Basically, if the object is not already in the tileset I need to find a position for it (i.e. 16 tiles, even if 15 should be ok).

Using pure screen 2, you have 16 "slots" of 16 tiles each in each bank, thus the total number of objects
on the screen at the same time is 16 per bank (i.e. 48 in total on 3 banks).

How do you get 64 ?

AR
En línea
SEPPASEPPA
Karoshi Newbie
*
Mensajes: 24


Email
« Respuesta #84 : 28 de Noviembre de 2008, 08:57:37 pm »

I did not fully understand you idea.
.....
How do you get 64 ?

AR
64 are the 256 tiles available on msx1 divided by 4 (assuming 2 pixel smooth scroll) different tile versions, one for each 2 pixel scrolled tile.

the idea is simple: look at this nametable layout:
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
.....

say for example that the tilenumber of 'A' is 0
and tilenumber of 'B' is 1

when x = 0 you only have tiles 'A' and 'B' on screen, because 'C' is on immaginary column 33.
when you scroll one charather left, the entire column of 'A' disappears and the tile pattern for 'A' is changed to reflect the image of the pattern 'C'. Plus the nametable is also updated. The tilenumber of 'B' does not change between scrolls is always 1. Instead the tilenumber of 'A' is 0 and is overwritten by the pattern of 'C' when the scroll takes place.


Problems arise when you have, for example one disappearing tile and two new incoming tiles and you have already used all 64 tiles. You will end up with 65 but is not possible because 65*4=260, that is greater than 256.

Hope is clear now,


« Última modificación: 28 de Noviembre de 2008, 08:59:33 pm por SEPPASEPPA » En línea
ARTRAG
Visitante
« Respuesta #85 : 28 de Noviembre de 2008, 11:53:04 pm »

Totally, it was clear also before, but without the info you plan to scroll with 2pixels steps it was impossible to get your numbers.
 
Assuming 2pixels steps, you get that each 8x8 object needs 2*4=8 tiles (or better 7 if we do not count the blank tile)

This means that each bank can represent 256/8 = 32 objects, or better 256/7=36 plus some spare tiles (among them one is the common blank tile).

Thus in total you can have 32*3 = 96 objects on the screen (or better 108)

Why 64 ?
En línea
SEPPASEPPA
Karoshi Newbie
*
Mensajes: 24


Email
« Respuesta #86 : 29 de Noviembre de 2008, 12:34:41 am »

Totally, it was clear also before, but without the info you plan to scroll with 2pixels steps it was impossible to get your numbers.

Sorry, i've forgot to mention this.

Citar

Assuming 2pixels steps, you get that each 8x8 object needs 2*4=8 tiles (or better 7 if we do not count the blank tile)

This means that each bank can represent 256/8 = 32 objects, or better 256/7=36 plus some spare tiles (among them one is the common blank tile).

Thus in total you can have 32*3 = 96 objects on the screen (or better 108)

Why 64 ?
64 x bank, assuming 2px scroller, (256/4) or in your example that is 1px scroller (as you said) 256/8 = 32 x bank. (not considering the blank tile, for simplicity)
anyway if you want (and i find it) i can send you a small demo.
En línea
ARTRAG
Visitante
« Respuesta #87 : 29 de Noviembre de 2008, 01:26:56 am »

Well, an object of 8x8 needs TWO tiles while scrolling.
This is why I say that an object needs 2*4 = 8 tiles (7 with the blank reuse).
For the same reason I say that each bank can hold up to 32 (or better 36) objects, thus having 32*3 (or 36*3) total objects on the screen.



« Última modificación: 29 de Noviembre de 2008, 01:29:01 am por AR » En línea
Páginas: 1 ... 4 5 [6]
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!