Enterprise Forever
:UK => Programming => Topic started by: ssr86 on 2016.February.18. 12:37:28
-
Just a proposition or recommendation of sorts...
Recently I've came across the gameboyJam site:
http://jams.gamejolt.io/gbjam3/games
http://jams.gamejolt.io/gbjam4/games
...and also have a look at the real gameboy games...
The 160x144 4color graphic mode has a real charm... at least for me.
...and the ep is capable of it.
You can have 160x144 4color with LPIXEL or CHAR modes.
A single screen buffer takes $1680 bytes when no scrolling. That's not much so you could preapre a clean buffer for speeding up the erasing of sprites. Could be quite fast. Don't know about using char mode but it is a possibility.
The downsides are that although you have wide pixels, the scroll would be in 4 pixel chunks... not very elegant. Also you would need more shifted sprites. Most TVs won't display some of the vertical lines so the hud may not be visible.
And with the nick's rich 256 color palette one could find some good 4-color themes.
Any other pros/cons?
PS: look at the game http://jams.gamejolt.io/gbjam3/games/stasis/31945 - this is a simple game that's certainly possible on the ep. Or look at the classic tetris for gb or maybe the duffy duck martian missions.
-
Emulating Gameboy games on EP.... a pity we don't have hardware sprites.
-
maybe we can find a game that not using many sprites
I will be happy if somebody converts a gameboy game :)
but as I remember, gameboy tile mode has many spec features like tile mirror etc
-
Well I didn't mean to emulate gb games but to point out that its "look" is possible to achieve on the enterprise and has some good tradeoffs.
Even so...without hardware sprites and "harware tiles" the games would simply have to be slower (25fps or less instead of 50fps), but still achievable if not too heavy on memory (and if jerky scrolling is ok as oppose to gb's smooth one pixel scroll).
-
Here (http://bgb.bircd.org/pandocs.htm#spriterambug) I've found explanations on how to write programs for the GB, but it also can serve to know how is organized the hardware.
-
I would prefer SMS , I think there are some games which can be converted, the graphics would be more blocky on EP.
-
But you can't achieve SMS exact look/gfx mode on the ep like you could with the gameboy's. And with the big pixels/ 4 colors you save quite some memory and gain some speed.
You could make the sprites bigger (screen wise at least) for less cpu time and memory (well maybe not memory, because you would have to make more versions of each for shifting).
However once again - I was more about what could be achieved with this mode (if you have art skills) and what are the pros and cons.
Although I'm aware that we won't be seeing original ep games anytime soon - only conversions... And that's because for that one needs proper art skills.
-
Don't forget that you have to emulate the CPU as well. Many people beleive it's Z80, but it's not, and that can cause the problems ... However at least, it's similar to Z80 (more similar to 8080 actually) so it won't be that hard :) But still much slower than native code ... However porting games to EP is another question than, maybe code can be modified/patched to be able to run with Z80.
-
Don't forget that you have to emulate the CPU as well. Many people beleive it's Z80, but it's not, and that can cause the problems ... However at least, it's similar to Z80 (more similar to 8080 actually) so it won't be that hard :) But still much slower than native code ... However porting games to EP is another question than, maybe code can be modified/patched to be able to run with Z80.
nem lehet kézzel vagy egy programmal átalakítani a kódot futtatás előtt? csak nem különbözik annyira...
-
nem lehet kézzel vagy egy programmal átalakítani a kódot futtatás előtt? csak nem különbözik annyira...
Manual correction is possible, automatic conversion by z80 code is much harder, or you have to find all places what should be patched.
-
IDA have option for "Z80-GB" CPU at disassembling.
-
Some instructions-opcodes have been removed, no problem, but other Z80 ones have been substituted by other GB specific opcodes (http://bgb.bircd.org/pandocs.htm#cpucomparisionwithz80).
-
Another weak point of the mode is the cost of scrolling. We need to update 144 modelines in the lpt every time we want to move the screen.
That's something like:
ld bc,15
ld hl,LPT+4
[...] sp set to a screenline addresses lookup table (at least for a vertical scroll)
rept 144
pop de
ld (hl),e
inc l
ld (hl),d
add hl,bc
endm
The cost is ~144*(10+7+4+7+11)=5616 cycles without setup and when unrolled (also without taking account of the ep specific waits).
-
Why need 144 modelines? Not enought one with 144 size? It is also have a crazy screen map?
-
Why need 144 modelines? Not enought one with 144 size? It is also have a crazy screen map?
With one modeline you won't get double lines and so the screen will be very small. And what I've meant with the gameboy "look" is 160x144 4-color fullscreen mode (so 144 modelines with LPIXEL and VRES zeroed).
EDIT:
But I guess it should be considered a worst case scenario... Because it wouldn't be hard to make an option to switch between the two: fullscreen double pixel and normal pixels but with smaller screen. That wouldn't need any changes in the screen buffer layout - only an exchange of lpt or changes inside the 144-modeline lpt (LPIXEL<->PIXEL and VRES off/on). The "update scroll" procedure could be made interchangeable also pretty easily (or just use conditionals).
EDIT2:
The smaller screen would make it easier to avoid flicker/tearing/dissaperaing of sprites when using only one screen buffer.
-
Possibly 1st a non scrolling game should be converted as a test to get the feeling, I started to convert a game from SMS about half year ago it is in relaxing phase now :D . The most difficult thing is converting Tile graphics display to EP, and the source has to be written from the program disassembly, but at least GB graphics should not be downgraded.
-
Possibly 1st a non scrolling game should be converted as a test to get the feeling, I started to convert a game from SMS about half year ago it is in relaxing phase now :D . The most difficult thing is converting Tile graphics display to EP, and the source has to be written from the program disassembly, but at least GB graphics should not be downgraded.
Is it Columns? :)
Actually a week ago I've started doing a "conversion" (not really a conversion because it has to be coded from scratch) of a pc game with gb-styled graphics myself :oops: . It needs vertical scrolling which I've started implementing just yesterday and that's the reason for my previous posts :P. It's pretty simple game so goes pretty fast (maybe also because I'm able to reuse some code from hattrick). For now I know about one problem that I don't really know how to tackle - wrapping of sprites (sprite going out on the right should appear in the same line from the left and clipped... I think I'll have to prepare clipped versions for those sprites and draw two of them - one on the right and one on the left... however it doesn't seem very optimal...)
However if another person wanted to do a proper conversion of a non scrolling game then maybe Tetris or Boxxle (sokoban) or some Game&Watch minigame?