On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit) (+3)
Do two of the colours blend with opacity to make a new colour? Wow buddy, looks like you're in more than four colour territory!

This is covered in the four colour rant.

That said, Gameboy games would try to avoid this flickering as best as possible as it indicates the sprite limit is exceeded (eight* sprites per scanline) - even when it did flicker it would only show one sprite or the other, or sections of a scanline - but never a transparency. There's a hazy line between "the game has four colours" and "the final render has more than four colours" - use your best judgement here, but be aware that people who are rating the games will be using their own best judgement.

*Ten sprites per scanline

(+1)(-2)

alright the palette rules seem really weird and arbitrary, and first of all are we speaking DMG flicker or MGB flicker? the DMG LCD was "smeary", mixing the last frame with the current, which with clever use of flicker would display as a 5th, 6th, 7th, or even 10th unique color.  the MGB doesnt blend as much

> Gameboy games would try to avoid this flickering as best as possible as it indicates the sprite limit is exceeded (eight sprites per scanline)

game boy games do not "avoid" it in any way shape or form, sprite shuffling* is done at all times as there is no* way to tell when the sprite limit is hit
sometimes flicker is intentional, but im too lazy to look for the point in a 4 hour video of links awakening where you show the ghost thier house. maybe you should play the game and see it for yourself :3

> (eight sprites per scanline)
GB has 10 sprites per scanline, the SMS and NES have 8.

> palette can be changed

thats a feature of the super game boy, shouldnt this also mean SGB borders should be allowed? and why only one palette? SGB compatibile could have 4 at once split into 8x8 nonscrolling regions

*the sprite priority is rotated each frame, as flicker is not a hardware feature, the hardware just doesnt render sprites past the 10th

*there is, prehistorik man does it

believe it or not but i know what im talking about, and if you dont believe, or wanna know how i know, check out https://gbdev.io, especially pandocs.

cheers!

(+2)

>the palette rules seem really weird and arbitrary

Yes. Welcome to GBJam.

(3 edits) (+1)

* Gameboy games do try to avoid the sprite flicker by trying not to overload the scanlines with more sprites than possible
* Some games utilise the sprite flicker
* Hardware blending and other tricks do not apply to the GBjam and we are not interested in explaining the subtleties of what is or isn't applicable for the competition.
* Render interrupt introduces more than four colours to the screen. The gameboy colour has more than four colours. Fingerpainting on the screen introduces more than four colours.
* Games made for GBJam have to display four colours on the screen at a resolution of 160x144 with the same limitations for input as the gameboy.
* SGB borders can be shown
* You are correct, it's ten sprites per scan line. I had forgotten.

The jam rules are as arbitrary as 1bit jam. Please accept this.

The GBJam is for all users at all levels of skill, and as such is very simplified. If you would like a more challenging jam, seek out Gameboy Compo when it returns.

(-1)

>Gameboy games do try to avoid the sprite flicker
i guess it depends on the game, usually theres not enough sprites to hit the limit
>[...]we are not interested in explaining the subtleties of what is or isn't applicable for the competition.

sounds reasonable to me

>Render interrupt introduces more than four colours to the screen.
(raster/STAT/LYC/scanline interrupt, first time hearing render interrupt, unless you mean vblank)

not really, the PPU still has the hardware limitation of 4, SGB is just post processing, and GBC isnt an "original" gameboy

>SGB borders can be shown

thats nice

>The jam rules are as arbitrary as 1bit jam. Please accept this.

i can accept that, i was just looking for anwsers as to why theyre so arbitrary

>If you would like a more challenging jam, seek out Gameboy Compo when it returns.

i have yet to finish a game in the first place, and the next compo is 2023, so no thanks

thanks for the quick reply, and have a nice day

This is why it's important not to bog yourself down in details of technical implications. The jam is open and vague enough so that anyone can make a game using any tools available to them without worrying about technical specifications.

I hope you enter this year or next and give a go at making a simple game!

(-1)

> This is why it's important not to bog yourself down in details of technical implications.

thats kind of how i manage scope, especially since i really want to develop gameboy homebrew.

>[...]anyone can make a game using any tools available to them[...]

as of right now the tools available to me are :

- RGBDS, which is literally a gameboy assembler (even then my main issue is chasing meaningless cycles (overoptimizing))

- Godot, which i simply dont understand, and refuse to understand

>I hope you enter this year or next and give a go at making a simple game!

by the time 2023 rolls by ill forget about this. willing to bet ill forget within a week, and i doubt id be happy with 'simple'

also you replied 22 hours sooner than i expected :p