#27003 - Caswynben - Fri Oct 01, 2004 2:10 pm
The game I am working on requires full screen (Or bigger) images for the player to walk around on. It is a graphic adventure in the vein of Monkey Island and Kings Quest. Which mode should I use? The bitmap modes would be perfect if I could use more than one layer. The tiled modes don't give me enough VRAM to load an entire image in.
Any advice?
#27004 - tepples - Fri Oct 01, 2004 2:44 pm
You can store about three 16-color "entire images" in the background part of VRAM at 19.2 KBytes each. Don't let "16-color" fool you; you can assign different 16-color palettes to different parts of the screen.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27005 - poslundc - Fri Oct 01, 2004 2:52 pm
You can easily fit an entire 256-colour image into VRAM in tiled mode if you want... you just can't easily fit a second one. Which means when going from one screen to another you'd have to have some kind of transition effect, such as fading to black, swapping in the new image and fading back up, or scrolling the background and dynamically swapping in the tiles of the new image as you scroll.
Unless you are planning on animating the kind of effects in the background that really need a direct buffer (such as particle effects, 3D, etc.) I'd recommend sticking to tile mode for the benefit of the additional backgrounds.
Dan.
#27007 - Caswynben - Fri Oct 01, 2004 3:03 pm
Okay, I just got afraid because I noticed that tiled mode only gives me 16K of VRAM to use for tile data and the GBA resolution being 240x160 = more than that. Bitmap mode has a spot for each pixel on screen (Which is what I'd need) and takes up twice as much VRAM (Eating into OAM Data). Perhaps I'm missing something?
#27009 - sajiimori - Fri Oct 01, 2004 3:53 pm
What you are missing is that the maximum BG tile space is more like 56K (or more if you assign a BG to char block 3 and use the top 512 tiles to overflow into sprite RAM, which I've never tried but I hear it works).
#27011 - poslundc - Fri Oct 01, 2004 3:56 pm
| Caswynben wrote: |
| Okay, I just got afraid because I noticed that tiled mode only gives me 16K of VRAM to use for tile data and the GBA resolution being 240x160 = more than that. Bitmap mode has a spot for each pixel on screen (Which is what I'd need) and takes up twice as much VRAM (Eating into OAM Data). Perhaps I'm missing something? |
You've got 64K of VRAM, not 16K, and your tiles can span more than one character-base-block. In 16-colour mode you can reference up to 1024 tiles (two full char-base-blocks worth; you only need 600 to fill the screen).
256-colour mode is trickier as it takes a little more than 2 char-base-blocks to fill the screen with tiles, and you can only reference 256 of them at a time. You can solve this problem either by using multiple backgrounds (which is a bit wasteful, but you're already using most of your VRAM anyway), or by using an HBlank/VCount interrupt to switch the character-base-block that the background points to at certain points along the screen.
In sum, tepples' suggestion of using 16-colour mode is probably best; you can use colour-quantization programs (search the forum) to break your image up into the necessary palette/tile combinations.
Dan.
#27013 - DiscoStew - Fri Oct 01, 2004 4:05 pm
Actually there is 96K of VRAM, but as poslundc was meaning to say, only 64K of it is used for backgrounds. Can't background maps/tiles be able to extend into sprite cel VRAM? That would help a little if you don't require a lot of sprite cel VRAM.
_________________
DS - It's all about DiscoStew
#27016 - poslundc - Fri Oct 01, 2004 4:36 pm
It would appear that Cearn debunked the myth in this thread.
Dan.
#27021 - DiscoStew - Fri Oct 01, 2004 6:42 pm
poslundc, the link you provided doesn't redirect to that thread, but I found it here. From what they said, it's not possible on hardware.
_________________
DS - It's all about DiscoStew
#27023 - poslundc - Fri Oct 01, 2004 6:45 pm
How very odd. I must need more practice with copy and paste.
Dan.
#27028 - ampz - Fri Oct 01, 2004 8:58 pm
| poslundc wrote: |
Unless you are planning on animating the kind of effects in the background that really need a direct buffer (such as particle effects, 3D, etc.) I'd recommend sticking to tile mode for the benefit of the additional backgrounds.
Dan. |
Not to mention hardware scrolling!
In a bitmap mode you have to rewrite the entire screen pretty much every frame if you do a scrolling game. That eats up a fair chunk of precious Vblank cycles.
Simply make your map/background so that some tiles are reused. With just some small adaptation of your (photoshop painted?) image, you can easily save a third of the tiles. (ground tiles and sky tiles, same cloud used several times, same tree used several times, and so on...) You really only need to save 40-80 tiles or so to make it fit in a 256 color tilemap, but you can usually save alot more than that, making room for more tilemaps.
If you make your map/background image from scratch in a good map editor instead of photoshop, then you will probably get away with like 100 tiles or so total.
#27030 - poslundc - Fri Oct 01, 2004 9:21 pm
| ampz wrote: |
Not to mention hardware scrolling!
In a bitmap mode you have to rewrite the entire screen pretty much every frame if you do a scrolling game. That eats up a fair chunk of precious Vblank cycles. |
According to GBATEK, you can use BG2's scroll registers to rotate/scale the bitmap modes.
Dan.
#27034 - ampz - Fri Oct 01, 2004 9:47 pm
| poslundc wrote: |
| ampz wrote: | Not to mention hardware scrolling!
In a bitmap mode you have to rewrite the entire screen pretty much every frame if you do a scrolling game. That eats up a fair chunk of precious Vblank cycles. |
According to GBATEK, you can use BG2's scroll registers to rotate/scale the bitmap modes.
Dan. |
rotation/scaling: yes.
wrap-around: no.
Without wrap-around you have to rewrite the entire screen if you want to do scrolling.
#27035 - poslundc - Fri Oct 01, 2004 10:03 pm
Hm. Does it make any difference if you set the wrap bit in BG2CNT?
Dan.
#27036 - ampz - Fri Oct 01, 2004 10:36 pm
Not entirely sure actually. I only remember doing some research two years ago and found that the bitmap modes does not support wraparound.
But I might very well be wrong.
Try it?
#27042 - tepples - Sat Oct 02, 2004 1:04 am
You can make a mode 3-5 bitmap wraparound vertically by using a vcount event to switch the scroll position.
Horizontal wraparound is a bit tougher. One method involves stretching the screen and then drawing the same thing to the left and right halves of the bitmap. Another method involves using the window to cut a few pixels off the left and right halves of the screen, smooth-scrolling the screen using the BG2 affine registers, and occasionally manually scrolling a jump at a time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27045 - Caswynben - Sat Oct 02, 2004 1:10 am
Perhaps I need a better primer on tile-based video modes then.
My problem so far has been that the documentation I read likes to branch off and go "Here's some random ASM that has nothing to do with what we're doing now!" or start explaining char-base blocks poorly.
Can anybody recommend a good guide for tiled modes? I read Harbour's book but got bogged down in his poor examples and bad structure.
If I went the bitmap route and used DMA to do the blits, could it be fast enough that I could treat the GBA screen a little more like in OpenGL?
And another question...Text. My game is going to display lots of text. What is the preferred method of displaying text on the GBA on top of existing graphics. Like a textbox that comes up in Monkey Island.
#27048 - Miked0801 - Sat Oct 02, 2004 1:25 am
Tried it a year ago and I believe it didn't work (wrap around.) Other more recent tests are welcome though :)
#27052 - poslundc - Sat Oct 02, 2004 3:46 am
| Caswynben wrote: |
Perhaps I need a better primer on tile-based video modes then.
My problem so far has been that the documentation I read likes to branch off and go "Here's some random ASM that has nothing to do with what we're doing now!" or start explaining char-base blocks poorly.
Can anybody recommend a good guide for tiled modes? I read Harbour's book but got bogged down in his poor examples and bad structure. |
http://www.gbajunkie.co.uk/
http://www.thepernproject.com/
Others out there as well... check the docs on the main site.
| Quote: |
| If I went the bitmap route and used DMA to do the blits, could it be fast enough that I could treat the GBA screen a little more like in OpenGL? |
That's what Mode 3 is designed for, but it's pretty complicated and rarely used. (There is a special DMA mode for working with it; I imagine it would be challenging to write a game architecture around it.) Modes 4 and 5 are designed to use double-buffering, so you draw into one buffer while the other is being displayed, then flip them.
| Quote: |
| And another question...Text. My game is going to display lots of text. What is the preferred method of displaying text on the GBA on top of existing graphics. Like a textbox that comes up in Monkey Island. |
Have a look at this thread.
Dan.
#27062 - ampz - Sat Oct 02, 2004 9:28 am
I agree with poslundc, http://www.thepernproject.com/ is very good at explaining tile modes.
From the sounds of it, the best route for you to go is to make the backgrounds in a map editor and use tilemodes. That's how flat scrollable backgrounds are made in GBA games.
Forget OpenGL. It has nothing to do with the GBA.
Text is most easily displayed using a 16 color tile mode background. 8x8 fonts are by far easiest, but variable width fonts look better and let you display more text on the same screen area.
#27066 - ampz - Sat Oct 02, 2004 10:47 am
| tepples wrote: |
You can make a mode 3-5 bitmap wraparound vertically by using a vcount event to switch the scroll position.
Horizontal wraparound is a bit tougher. One method involves stretching the screen and then drawing the same thing to the left and right halves of the bitmap. Another method involves using the window to cut a few pixels off the left and right halves of the screen, smooth-scrolling the screen using the BG2 affine registers, and occasionally manually scrolling a jump at a time. |
Just for the fun of it.. Do you think it is technically possible to set up a timer DMA event to change horizintal scroll position mid scanline?
The timer must be started with cycle-exact precision.. I imagine setting up a Hblank DMA transfer to set the timer configuration registers might do it..
EDIT
Just realized that there is no easy way to trigger a DMA transfer on a timer event.. Hmm, it must be possible to get around that somehow...
#27070 - poslundc - Sat Oct 02, 2004 2:43 pm
Changing stuff during HDraw? Without creating screen artifacts? Good luck with that... all bets are off once the scanline begins rendering.
Dan.
#27072 - ecurtz - Sat Oct 02, 2004 4:35 pm
This guy has already ported the engine needed to play the original Sierra games onto the GBA.
GBAGI Homepage
Why not just author your game in one of the home brew Sierra editors and use his system to run it on the GBA?
On the scrolling bitmaps front - it seems like as long as your graphics aren't compressed, which isn't a huge deal for homebrew stuff, you can just blit it up there every frame. Sure it's expensive, but probably less than 20% of your cycles, even at 60fps... I thought it would be fun to do a demo side scroller using full 16 bit painted backgrounds.
#27074 - ampz - Sat Oct 02, 2004 4:57 pm
| ecurtz wrote: |
This guy has already ported the engine needed to play the original Sierra games onto the GBA.
GBAGI Homepage
Why not just author your game in one of the home brew Sierra editors and use his system to run it on the GBA?
On the scrolling bitmaps front - it seems like as long as your graphics aren't compressed, which isn't a huge deal for homebrew stuff, you can just blit it up there every frame. Sure it's expensive, but probably less than 20% of your cycles, even at 60fps... I thought it would be fun to do a demo side scroller using full 16 bit painted backgrounds. |
240*160=38400pixles (16bits each).
ROM timings are 2 cycles per 16bit read, and VRAM timings are 1 cycle per 16bit write, right?
38400*3=115200cycles.
There are only 83776 Vblank cycles, so your DMA transfer will take 138% of your Vblank cycles.
You would have to use most of your Hblank cycles as well to get that frame DMA:ed to VRAM in time.
#27076 - ecurtz - Sat Oct 02, 2004 6:00 pm
Why can't we use 32 bit transfers? Does the bus not support that? Obviously I don't know this stuff well, just figuring it out. But it seems like using the cpu and doing ldm/stm of say 8 words at a time.
One line: 240 16bit pixels = 120 words = 15 ldm/stm @ about 24 cycles per pair = 360 cycles per line or 57600 cycles for the screen.
I must be missing something about theoretical cpu transfers versus actual hardware.
#27077 - tepples - Sat Oct 02, 2004 6:22 pm
The bus to both the cartridge and the VRAM is 16-bit. However, you could blit starting in vblank and finishing in draw, as GBA VRAM is dual-ported.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27091 - ampz - Sun Oct 03, 2004 1:47 am
Yes. I imagine pogoshell's built in BMP viewer probably do that.
The VRAM is supposed to be dual-ported, but I read somewhere that CPU accesses to VRAM can be stalled a few cycles during draw... Does anyone know what that's all about?
ecurtz: You can do 32 bit accesses if you want, but since both VRAM and cart ROM are 16bits wide, you will not gain anything from it. One 32bit access results in two 16bit hardware accesses.
I don't see where you get the 24 cycles per ldm/stf pair numbers.
#27094 - tepples - Sun Oct 03, 2004 1:57 am
I've tested the speed of DMA to VRAM on GBA hardware, and DMA from EWRAM to VRAM during draw was about 10 percent slower than if VRAM were actually dual-ported. Granted, this was in tile mode rather than bitmap mode, but if you start DMAing your image at the start of vblank, you should be able to stay far ahead of the raster.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27097 - ecurtz - Sun Oct 03, 2004 5:34 am
| ampz wrote: |
ecurtz: You can do 32 bit accesses if you want, but since both VRAM and cart ROM are 16bits wide, you will not gain anything from it. One 32bit access results in two 16bit hardware accesses.
I don't see where you get the 24 cycles per ldm/stf pair numbers. |
I was going off the cycle counts in Robin Watts' "ARM Instruction Formats and Timings". But obviously that doesn't match up to the reality of the GBA hardware. I should spend more time reading the spec before getting into these discussions - maybe somebody will be inspired by the GBAGI link at least...
#27099 - ampz - Sun Oct 03, 2004 9:32 am
| ecurtz wrote: |
| ampz wrote: | ecurtz: You can do 32 bit accesses if you want, but since both VRAM and cart ROM are 16bits wide, you will not gain anything from it. One 32bit access results in two 16bit hardware accesses.
I don't see where you get the 24 cycles per ldm/stf pair numbers. |
I was going off the cycle counts in Robin Watts' "ARM Instruction Formats and Timings". But obviously that doesn't match up to the reality of the GBA hardware. I should spend more time reading the spec before getting into these discussions - maybe somebody will be inspired by the GBAGI link at least... |
ARM instruction timings (cycle counts) depend entirey on the hardware. (The speed of the memory used)
#27222 - Caswynben - Wed Oct 06, 2004 11:58 pm
A little update.
My problem now is that I can't get anything to display properly, it just goes nuts now when I try to convert a 256x256 image into a map using gfx2gba.
I load all the information in (4,400 for the tiles) and then it's just garbage.
Any tips?
#27223 - sajiimori - Thu Oct 07, 2004 12:06 am
Use VBA to see what's getting loaded.
Look at the data that gfx2gba outputs to see if it's what you expect.
Make a list of the things you have to do to get your graphics on the screen, and double check that you're doing all of them.
Use simpler graphics so you can recognize the patterns by looking at the raw data.
Generate some tiles and maps algorithmically (like making a checkerboard pattern) and make sure you know how to display those.
Whatever you do, don't stare at your code or your brain will go completely blank like mine always does. ;)
#27228 - Caswynben - Thu Oct 07, 2004 12:44 am
Well, I know I can display simple things that actually use tiles, but I think the problem is that the data I need to load into character data is 38400 now.
(I did fix the earlier problem). However, apparently I can only load half of that into one character block, and then I assume that the rest gets loaded into the next character block. How would I get 240x160 pixels of graphics into memory? Perhaps someone could point me to how to do that 16-color thing.
#27230 - sajiimori - Thu Oct 07, 2004 1:06 am
If you want to to 16 color tiles, follow one of the various tutorials on the subject (Pern is the perennial favorite), and let us know where you get stuck.
#27238 - ampz - Thu Oct 07, 2004 6:39 am
You can use more than one character block.
#27247 - Caswynben - Thu Oct 07, 2004 3:49 pm
| ampz wrote: |
| You can use more than one character block. |
How?
And Pern didn't have a tutorial on 16-color tiles. They barely have one on 256 colored ones.
#27251 - ampz - Thu Oct 07, 2004 5:23 pm
There is nothing to it... Just do it.
You can fill the entire VRAM with tiles for a single background if you want.
#27252 - Caswynben - Thu Oct 07, 2004 5:46 pm
| ampz wrote: |
There is nothing to it... Just do it.
You can fill the entire VRAM with tiles for a single background if you want. |
Well, I tried that and grabbed the address for charblock 0 and filled in 38K of stuff. Except only about half of that ends up displaying on the screen. Do I need to switch char blocks for the background halfway through the screen?
#27254 - poslundc - Thu Oct 07, 2004 5:52 pm
I answered this question earlier in the thread:
| I wrote: |
You've got 64K of VRAM, not 16K, and your tiles can span more than one character-base-block. In 16-colour mode you can reference up to 1024 tiles (two full char-base-blocks worth; you only need 600 to fill the screen).
256-colour mode is trickier as it takes a little more than 2 char-base-blocks to fill the screen with tiles, and you can only reference 256 of them at a time. You can solve this problem either by using multiple backgrounds (which is a bit wasteful, but you're already using most of your VRAM anyway), or by using an HBlank/VCount interrupt to switch the character-base-block that the background points to at certain points along the screen.
In sum, tepples' suggestion of using 16-colour mode is probably best; you can use colour-quantization programs (search the forum) to break your image up into the necessary palette/tile combinations. |
Dan.
#27258 - sajiimori - Thu Oct 07, 2004 6:38 pm
Dan, don't you mean you can access 512 8-bit tiles, not 256?
I've always been confused about the screen data for 8-bit text BGs (probably because I only ever use 4-bit). Shouldn't the GBA shift the char index left 1 bit (and assume a 0 as the low bit) to allow access to all 4 char blocks?
#27261 - poslundc - Thu Oct 07, 2004 7:40 pm
| sajiimori wrote: |
| Dan, don't you mean you can access 512 8-bit tiles, not 256? |
Um, yes, I was thinking of the difference between rot and text BGs, not the difference between 256 and 16 colour modes. Thanks for clearing that up.
Dan.
#27271 - ampz - Thu Oct 07, 2004 9:42 pm
512 unique tiles is usually more than enough to fill the entire screen, unless all tiles are unique.
But your graphics is very poorly designed (as in: not at all suitable for this application) if all background tiles are unique.
There are 600 tiles on screen.
#27272 - sajiimori - Thu Oct 07, 2004 10:05 pm
ampz, don't overgeneralize. Broken Sword is just one game that used backgrounds with most or all unique chars. I haven't played that many GBA games -- anybody know of others?
BTW, there are potentially 651 chars visible on one layer.
#27285 - ampz - Fri Oct 08, 2004 6:35 am
You are right, there are some special cases where almost all tiles need to be unique. Like in games where you modify the background on a pixel level. (blowing things up, building new things...)
#27297 - Miked0801 - Fri Oct 08, 2004 6:17 pm
Photoshopping ultra kick @ss graphics :)
#27322 - Caswynben - Sat Oct 09, 2004 4:25 pm
Okee dokee, I've managed to create an image with 16 16 color palettes in Quither. Now what? What tool should I use to convert this image into a GBA-readable format? GFX2GBA gets upset because it has 256 colors.
Should I split the image up into 16 pieces? This seems like overkill. How is there not a tool that will go through a 256 color image that has been split palette wise like mine and create a palette and a tileset that I can just put in? It seems like there's a tool for everything else.
I have been trying to figure this out, but there are certain things that I just don't see written anywhere. I see all kinds of info on how to quantize the image, but not how to go from that to the GBA. I mean, I suppose I could go through and start setting bits in my maps to use the right palettes...But I'm not sure if that would work.
#27396 - tepples - Tue Oct 12, 2004 5:52 am
Write a program that does each of these steps: - Read a .bmp file based on the spec at wotsit.org, or read a .png file based on the libpng examples.
- Convert it to a 16-color image by stripping off the high bits.
- Write out this 16-color image in a GBA readable tile format, either verbatim or compressed.
- Write out the high bits of the upper-left pixel of each tile in order.
Then on the GBA, decompress the tiles into a pattern table, and write out each set of high bits to each successive space in a map, along with the corresponding tile number.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.