Gameboy Development Forum

I update this thread with two new screenshots shared via Twitter.

Here we can see the Lilian killing a group of enemies. It is still not very polished, but the idea is that these fights resemble those of Musou/Warriors type video games:


https://twitter.com/Imanolea/status/856189107420237824


And here a first outline of the title screen. The letters emit a few small flashes, as in the title screen of Link's Awakening:


https://twitter.com/Imanolea/status/859056084027416576

I hope you like it.

Last edited by Imanolea (2017-05-01 11:07:46)

Thanks tmk. I think that lately there is a lot of people that are also doing quality looking stuff for Game Boy.

The first version of the game is planned for regular Game Boy and it will have additional features for Super Game Boy. Dedicated graphics for Game Boy Color are being considered for future versions.

Last edited by Imanolea (2017-05-01 13:15:45)

Imanolea wrote:

Thanks tmk. I think that lately there is a lot of people that are also doing quality looking stuff for Game Boy.

Don't want to hijack your thread but the last time I checked only Tobu Tobu Girl looked/sounded awesome. And I somehow can't imagine playing it on Brick, my eyes would hurt too much from bluring/ghosting.

Once more your game looks pretty amazing. From what you show on the screenshots, the game seems to be somewhat "Zelda-esque". Are you planning to include extensive storytelling  (like in the Zelda games) or do you mainly focus on action/fighting?

Imanolea wrote:

In Last Crown Warriors I have built a flickering system to prevent certain sprites from being permanently invisible, rotating in each frame the directions of the sprites of the enemies in OAM RAM. Curiously, this works, even though the X coordinate of the enemies is not being changed. So I suspect that the hardware takes into account something more than this coordinate when it comes to leaving out a sprite in a line.

http://i.giphy.com/3o7TKOUAQRuDIO2c24.gif

In that particular example, consider prioritizing hiding grass sprites (or whatever other low importance sprites may exist) before hiding enemies or the player sprite.

I also wonder what you mean by the second sentence. The 10 sprite limitation only applies to horizontal lines. This is because the screen is drawn one line at a time. If you change the Y coordinate to hide the sprite, the sprite is effectively dead and doesn't affect anything on screen.

Thanks Jonas, I've tried to limit the scope of the game in order to be able to be able to finish it in a feasible in a feasible period of time.

nitro2k01 wrote:

Imanolea wrote:

In Last Crown Warriors I have built a flickering system to prevent certain sprites from being permanently invisible, rotating in each frame the directions of the sprites of the enemies in OAM RAM. Curiously, this works, even though the X coordinate of the enemies is not being changed. So I suspect that the hardware takes into account something more than this coordinate when it comes to leaving out a sprite in a line.

http://i.giphy.com/3o7TKOUAQRuDIO2c24.gif

In that particular example, consider prioritizing hiding grass sprites (or whatever other low importance sprites may exist) before hiding enemies or the player sprite.

I also wonder what you mean by the second sentence. The 10 sprite limitation only applies to horizontal lines. This is because the screen is drawn one line at a time. If you change the Y coordinate to hide the sprite, the sprite is effectively dead and doesn't affect anything on screen.

I mean that to avoid that the sprite of a particular enemy is left without drawing due to the hardware limitation of 10 sprites per horizontal line, I rotate the addresses in OAM RAM of these enemy sprites. That is, I do not change any attribute of the sprite and only change the address in which they are stored. And this produces a flickering effect by which the sprite that remains without drawing varies.

The point is that I am not certain about what condition takes into account the hardware when deciding which sprite to leave without drawing (in case that are more than 10 sprites in the same horizontal line).

ISSOtm wrote:

Imanolea wrote:

The point is that I am not certain about what condition takes into account the hardware when deciding which sprite to leave without drawing (in case that are more than 10 sprites in the same horizontal line).

It depends on whether you use GBC features or not. From what I've seen from your screenshots, you use GBC. In that case, the first sprite in the table has the highest priority.
On a DMG or in compatibility mode, the horizontal coordinate instead serves as priority (the lowest coordinate being the highest priority), the tie breaker being the same as in GBC mode.

Source :

Pan Docs wrote:

When sprites with different x coordinate values overlap, the one with the smaller x coordinate (closer to the left) will have priority and appear above any others. This applies in Non CGB Mode only. When sprites with the same x coordinate values overlap, they have priority according to table ordering. (i.e. $FE00 - highest, $FE04 - next highest, etc.) In CGB Mode priorities are always assigned like this.

Right now the game don't uses any GBC feature and is compatible with the regular Game Boy (the byte 0x143 in the cartridge header is 0). The screenshot are taken from BGB, but from what I have been able to test the behavior that is shown in the .gif files is the same that happens in a real Game Boy.

And just having the Pan Docs in mind, and in relation to what I said before, I do not understand why even without changing the X coordinate of the sprites, they are flickering. According to the documentation, only those who share the highest X-coordinate value of their horizontal line should be flickering. The thing is that the left side of screen sprites are also flickering. And again, I'm just changing his address in OAM RAM.

http://i.giphy.com/3o7TKOUAQRuDIO2c24.gif

I don't know if I've explained myself.

Last edited by Imanolea (2017-05-07 06:07:06)

I am the first to be surprised with this issue. I'm going to leave some evidence to help us identify this Game Boy mystery. Either the documentation is incorrect, or there is something we are not taking into account.

First this video in slow motion from BGB 1.5.3.

https://drive.google.com/file/d/0B5Etmv … sp=sharing

And then this revealing frame of the game running in a Super Game Boy. We can see how the sprite that remains unpainted does not have the highest X coordinate of its horizontal line.

https://drive.google.com/file/d/0B5Etmv … sp=sharing

@Imanolea : I am also pretty confused. Although maybe the SGB has different rendering priorities from the DMG, since it's running on a SNES.
(Yet your first recording was on DMG. So I'm even more confused.)
I guess the answer is somewhere in the PPU. Maybe you should take this to the hardware board.

@gekkio : this is from a DMG, SGB, or CGB in DMG mode. So in theory your notes should be correct, but for some reason the rightmost sprite is redrawn, and sprites to its left aren't.
So... even though this sprite flickering shouldn't work, it does. (Also shoutouts to BGB for emulating this correctly )

(Makes me think... maybe you should ask the BGB developer, then ?)

Last edited by ISSOtm (2017-05-07 10:04:12)

Ok, I misread you.

I will update the Pan Docs on the wiki, since they state

Only 10 sprites can be displayed on any one line. When this limit is exceeded, the lower priority sprites (priorities listed above) won't be displayed.

Which is incorrect in the DMG's case.

Thanks Imanolea for pointing this out, and gekkio for, well, giving the answer

Yeah @nitro2k01, you are right.

It is still in development but I will try to remember that kind of thing. Right now the protagonist's sprites for example never rotate and are kept in the lowest address of the OAM RAM. I will most likely remove the grass of the game, but it seems to me a good advice and I will keep it in mind for this or other possible complementary sprites of enemies. It is better not to show an impact sprite than to have the enemy disappear.

Thanks.

Last edited by Imanolea (2017-05-08 11:18:16)

It's been a while since I last wrote this thread. So I'm going to post here the progress.

Lilian dodging and attacking: https://twitter.com/lightgamesgb/status … 7415532544

Lilian running: https://twitter.com/lightgamesgb/status … 8520601601

Character and scenario selection screen: https://twitter.com/lightgamesgb/status … 7409997824

A post about how the selection screen has been made: https://t.co/aW10EEfbxf

I hope you like it. At the moment the game is going well, I hope to have a demo ready in November.

Last edited by Imanolea (2017-10-08 17:56:56)