Home » News » Software » Losaben Akel announced
Losaben Akel announced

Losaben Akel announced

by snout on 23-12-2012, 15:24
Topic: Software
Tags: ASM, Kiki Kaikai, Knightmare, Losaben Akel, GFX9000
Languages:

Spanish MSX development group ASM have announced Losaben Akel, a remake of several MSX games for GFX9000 and MSX turboR. Development of the game has already progressed very far, as this preview reveals.

Each level in the game is to become a remake of a different MSX game. The first level of the game is a remake of Konami's Knightmare, whereas the second level will be a remake of Taito's Kiki Kaikai. The graphics of all 7 levels have already been created.

On their blog, ASM give extensive details on the status of the project and information about the development environment he uses.

Relevant link: ASM

Comments (16)

By Vampier

Prophet (2405)

Vampier's picture

23-12-2012, 18:07

they spelled my last name wrong Wink

By meits

Scribe (6530)

meits's picture

23-12-2012, 19:20

How Akelig Wink

By PingPong

Prophet (4088)

PingPong's picture

23-12-2012, 19:49

Graphically it's very similar to MSX1, except for the better sprites and smooth scrolling.

Does the score bar use a screen split or are simply hw sprites?

By guantxip

Paragon (1605)

guantxip's picture

23-12-2012, 20:20

First stage is the most simple of the game, is the link between msx world and gfx9000 world without trauma for the difference of vdp. And means too the gfx9000 are not a alien hard for superproductions, you can make games with msx1/2 style with a few more colours or sprites in screen erasing flickering. Use gfx9000 doensn't mean make a 16megas games like Snes. Next stages will be more powerful.

By assembler

Champion (408)

assembler's picture

23-12-2012, 20:23

Is a screen split. I use sprites to hide some garbage and to avoid enemies sprites walk over it.

By snout

Ascended (15187)

snout's picture

23-12-2012, 20:43

Very wise development decisions, lads! Really looking forward to this. My GFX9000 has been collecting dust for far too long! Smile

By PingPong

Prophet (4088)

PingPong's picture

23-12-2012, 20:51

assembler wrote:

Is a screen split. I use sprites to hide some garbage and to avoid enemies sprites walk over it.

Do you get garbage because of screen split? can you explain, please?

By PingPong

Prophet (4088)

PingPong's picture

23-12-2012, 20:52

guantxip wrote:

First stage is the most simple of the game, is the link between msx world and gfx9000 world without trauma for the difference of vdp.

Was, not a criticism. It's a like a retro-thing.

By assembler

Champion (408)

assembler's picture

23-12-2012, 21:04

the interruption is fired at line 192. At this point, I set R#17 to 0xff and R#18 to 128. Changes of SCAY8-SCA12 are ignored outside vertical retrace.

This change is not made immediately, so, there is some pixels, varying from 30, 40 aprox, of the "normal" screen, before the screen split shows the scoreboard. Is the same effect as in AshGuine http://www.youtube.com/watch?v=qR5t8lqVq6Q

To avoid this effect, I use 16 sprites with two black lines just in that point. Sprites are not affected by scroll registers. Also, 16 is the horizontal sprite limit. As they are at uppermost priority, no other sprite will appear over the scoreboard.

By PingPong

Prophet (4088)

PingPong's picture

23-12-2012, 23:25

assembler wrote:

the interruption is fired at line 192. At this point, I set R#17 to 0xff and R#18 to 128. Changes of SCAY8-SCA12 are ignored outside vertical retrace.

This change is not made immediately, so, there is some pixels, varying from 30, 40 aprox, of the "normal" screen, before the screen split shows the scoreboard. Is the same effect as in AshGuine http://www.youtube.com/watch?v=qR5t8lqVq6Q

To avoid this effect, I use 16 sprites with two black lines just in that point. Sprites are not affected by scroll registers. Also, 16 is the horizontal sprite limit. As they are at uppermost priority, no other sprite will appear over the scoreboard.

thx of explanation. It's a shame that this effect could not be done on V9990 as on V9938.

By mohai

Paladin (995)

mohai's picture

26-12-2012, 12:34

Looks very nice Smile

Did you try to use second plane instead of overlapping sprites?
I know GFX 9000 can manage 2 screen planes but i do not know how sprites behave when overlapping happens between both planes.

By assembler

Champion (408)

assembler's picture

26-12-2012, 20:50

This level uses only one plane. Next levels will use both planes.

In P1 mode you have two priority levels:

POINT OF VIEW -> [All sprites in front of plane A *] [PLANE A][All sprites in front of plane B #][PLANE B][Border][Superimpose]

An sprite with priority 0 in # will appear behind an sprite with priority 1 in * (different plane)
An sprite with priority 0 in * will appear in front of an sprite with priority 1 in * (same plane)

In the engine that we are using, there are 5 levels of priority sprites (software priority). So I make sure that the question marks are always behind another sprite. The player is always ahead of any other sprite, except when it dies, which happens to be below the other objects, except the question marks.

By Manuel

Ascended (19229)

Manuel's picture

26-12-2012, 22:58

I'm very excited to finally see some concrete development for GFX9000!

Oh, and if you can help to improve openMSX emulation accuracy of the GFX9000, please let us know!

By msd

Paragon (1510)

msd's picture

29-12-2012, 13:52

Looks promising. did you have any problem assembling the g9klib with tniasm?

By assembler

Champion (408)

assembler's picture

29-12-2012, 16:10

No problems. Only a lot of replaces to adapt the syntax.

By max_iwamoto

Hero (627)

max_iwamoto's picture

30-12-2012, 22:10

assembler wrote:

the interruption is fired at line 192. At this point, I set R#17 to 0xff and R#18 to 128. Changes of SCAY8-SCA12 are ignored outside vertical retrace.

This change is not made immediately, so, there is some pixels, varying from 30, 40 aprox, of the "normal" screen, before the screen split shows the scoreboard. Is the same effect as in AshGuine http://www.youtube.com/watch?v=qR5t8lqVq6Q

To avoid this effect, I use 16 sprites with two black lines just in that point. Sprites are not affected by scroll registers. Also, 16 is the horizontal sprite limit. As they are at uppermost priority, no other sprite will appear over the scoreboard.

I think this can be solved without use of sprites. Please check our English translation of Ashguine 2:

http://msxfiles.com/ashguine_2.php

The way I did it is next:

Keep whole VRAM page 3 as black (default on most MSX2. On Daewoo you need to fill it with zeros).
And this is the order of how things work inside interrupt handler when line interrupt triggered:

1. Set VRAM page 3
2. Disable line interrupt
3. Set current Y offset for VRAM page 0 where your game map is rolling.
4. Enable sprites. (they were disabled in my version to speed up a little bit).
5. Set VRAM page 0

Hope this helps.

Max