gbadev.org forum archive

First of all, hello, I'm a noobie around these parts and am yet to even own a GBA with flash card although that will be sorted out by x-mas day :D, this is more of a first hello with the much needed self pimpage.

This doesn't mean that it's not time to start learning, my main vice is texture creation although this so far has been mainly for Quake3Arena which normally uses 256x256 images, from what I have read then the largest texture size for the GBA is 128x128 with a total palate colour of 256, is that correct?

I'm currently taking part in a Capture the flag texture challenge which I'm helping to Administrate over at the Map-center (A 3D engine Level editing forum) and feel that a lot of the work that?s produced for this challenge would be usable if tweaked slightly to use in GBA game development. Most of the Work produced is freely available for non-commercial use.
Here's a link to the Map-center CTF challenge thread for those that are interested.

Here's a selection of my tiled textures that may be usable for a GBA project, they are currently in tga format so would need tweaking using Image/Mode/Indexed Colour (photoshop) or whatever your preferred graphics package is. Please feel free to use for whatever.

[Images not permitted - Click here to view it]
Grass
& Rocks
Click here to download both of these 1.98mb .tga organic texture sets.

Click here to view older image's of my current Q3A texture project, for those that are interested.

I have no programming skills so making a game by myself is out of the question, although hope work as a part of a team in the future, have fun whatever your working on, also cheers for the site & forums.

eskimo_roll wrote:

This doesn't mean that it's not time to start learning, my main vice is texture creation although this so far has been mainly for Quake3Arena which normally uses 256x256 images, from what I have read then the largest texture size for the GBA is 128x128 with a total palate colour of 256, is that correct?

Well, you haven't been misinformed per se... while the GBA can handle that, the reality of GBA programming is that textures are usually much, much smaller. A typical grass texture would probably be somewhere on the order of 16 x 16 pixels.

Keep in mind that the GBA's screen is only 240 x 160 pixels to begin with. Even if it wasn't a huge waste of resources programmatically, having a 128x128 tilable texture for grass wouldn't make much sense, as you would be tiling an image that already consumes nearly half the screen.

On the colour side of things, the total palette is 256, but that's for everything, at least, your entire background, which means a typical grass texture wouldn't consume more than 3 or 4 colours.

If you want to design for the GBA, you will probably have to leave the high-level Photoshop brushes, filters, etc. behind and start working one pixel at a time. It's simply the nature of the medium.

That said, if you're interested in some project work I have recently opened up my game project to some graphic artists. You can get the information at http://www.danposluns.com/eod; although I am first and foremost looking for a sprite (ie. character) artist I am also definitely looking for background and texture artists as well, so if you want to give the kind of drawing it needs a shot then you can feel free to apply.

Dan.

poslundc, cheers for that feedback, I understand that 256 colours v limited to make a world, will experiment with this.

poslundc wrote:

Keep in mind that the GBA's screen is only 240 x 160 pixels to begin with. Even if it wasn't a huge waste of resources programmatically, having a 128x128 tilable texture for grass wouldn't make much sense, as you would be tiling an image that already consumes nearly half the screen.

Note taken on screensize, again cheers. I suppose it would depend on the game's requirements graphically as to what resolution images are needed, if a smaller gameworld is used then that would allow more colours to be used for each texture as less seperate textures would be needed. On the other hand a large gameworld with varied texture styles would need less colour usage per texture, in terms of graphics optimisation a lot of choices would need to be made depending on the game in question. That's IMHO :D.

poslundc wrote:

If you want to design for the GBA, you will probably have to leave the high-level Photoshop brushes, filters, etc. behind and start working one pixel at a time. It's simply the nature of the medium.

Remember there's always more than one way to cook a chicken, it's the taste that counts, With texture creation it's always better to draw too large & then half the image size it means that you end up with a more detailed image, the colour count can always be dropped using image/mode/indexed, there is no right & wrong, just good results.

poslundc wrote:

That said, if you're interested in some project work I have recently opened up my game project to some graphic artists. You can get the information at http://www.danposluns.com/eod; although I am first and foremost looking for a sprite (ie. character) artist I am also definitely looking for background and texture artists as well, so if you want to give the kind of drawing it needs a shot then you can feel free to apply.

Quote:

With texture creation it's always better to draw too large & then half the image size it means that you end up with a more detailed image

I agree that this method is useful in many situations, but I also think it's a bad idea to take it for granted that your results will be better this way. Scaled-down images often suffer from a lack of sharp edges and contrasts, which are essential in very-low-resolution graphics -- especially on a tiny, dark LCD.

Try drawing a high-res brick tile and scaling it down to 16x16, and compare the results to drawing a 16x16 tile directly. I bet you'll have a hard time getting a good contrast between the bricks and the mortar for the scaled-down image.

Cheers for that advice Sajiimori, this texture (shown above) fit's your description well (the negative one), it's also twice the size you asked for & just as noticeable (that could be worked around if using larger stock), the motor would need a lot more definition.

[Images not permitted - Click here to view it]

I do agree that not all textures need to be worked on a larger scale, some it's possible to get around using the 1:1 scale just for time saving aspects.

I thought I'd share another little tilp for testing repeating patterns on textures.

here's a grass image that I made as a result of looking at dans grass texture comment. it has 5 colours (according to photoshop, I can only count 4, guessing that white counts as one even though it's not seen, right?) any, here's the image:

[Images not permitted - Click here to view it]

Click here to view the tiling test, it's double the gba format for me to get a better feel for the scale.

Here's the code, just copy it change the textures name & drop the texture in the same file, the size can be changed by altering the width & height peramiters.

Code:

Cheers btw for the warm reception.

You would want to try out your graphics on a real gba aswell to see what the screen do to your colors.
_________________
You can't beat our meat

IMO, doing an actual test on a gba screen is not as important as it seems.

As long as the graphics are consistent in their use of brightness, color, and contrast, the process of color correction can be delayed until the last possible moment -- at which point a script can batch process the whole lot of them. Then the artist doesn't have to worry about color correction -- they can just use the colors that look best on their screen.

An added benefit of this method is that the original graphics will be more independent of the color quirks of the target medium.

Does anybody know what kind of adjustments are necessary to adapt an image to the dark, muddy GBA screen? I noticed that the colors in e.g. The Lost Vikings for GBA are very different from the original SNES version (when viewed in an emulator), but they look great on the GBA screen. Blizzard must have found the right parameters for their filter.

Hmm, I have to disagree here a bit. It's always a good idea to see art on target as soon as possible. This allows the artists to immediately learn what works and what doesn't. While it's true that a last second script run of all art through debabilizer or whatever will get you somewhere close to what appears on target, it won't compare to someone immediately seeing the art on target and being able to fix it now. The clients also appreciate good looking art immediately instead of being told "Don't worry, it'll look good at Alpha/Beta when it's all done."

My .02 worth - Mike

I guess I should have been more specific. By "last possible moment", I don't mean in the last minute of the project schedule (that would obviously be unwise) -- I mean in the last step of the iteration. The artists should keep their original versions of all their graphics, and the images should be adapted on the fly during the build process, after which the artists will be able to see their work on the GBA.

If you want them to see their work on screen with less latency than an iteration, you can give them a simulator or some test hardware or something. But then you run the risk of having them 'fix' everything prematurely, which is the aspect of your point of view that I disagree with. I do not think it should be the artist's responsibility to adjust their graphics to fit the color and brightness offsets of the LCD, for these reasons:

1) While producing their work, they will not be looking at the colors the way they will look on the screen.

2) It will be harder to adapt the graphics to other displays (for ports to other platforms, new versions of the GBA display, or screen captures for marketing).

3) If the adjustments they make are determinted to be inadequate, readjusting them will be more difficult and could result in additional loss in quality.

The GBA gamma is higher quite a bit higher than the 2.2 standard for CRT monitors. But, gamma adjustment is pretty straitforward to implement in a conversion tool. tepples does it in his tools; here is a snippet from his getpal.c:

Code:

/* rgb2gba() ******************************
Convert an RGB color in (0..63) to a gamma-corrected GBA color in (0..31).
*/
unsigned int rgb2gba(const RGB *color)
{
return ((int)sqrt(color->b * 16) << 10)
| ((int)sqrt(color->g * 16) << 5)
| ((int)sqrt(color->r * 16));
}

It's even pretty easy to adjust the palette on the GBA itself. (See gbadev 10750.) Many commercial games give the user the ability to configure it.

gbadev.org forum archive

Announcements And Comments > Noobie texture artist says hello.

#12956 - eskimo_roll - Tue Dec 02, 2003 4:36 pm

#12962 - poslundc - Tue Dec 02, 2003 6:40 pm

#12964 - eskimo_roll - Tue Dec 02, 2003 8:21 pm

#12972 - sajiimori - Tue Dec 02, 2003 9:59 pm

#12987 - eskimo_roll - Wed Dec 03, 2003 12:13 am

#13024 - Touchstone - Wed Dec 03, 2003 10:08 pm

#13031 - sajiimori - Thu Dec 04, 2003 12:13 am

#13036 - Miked0801 - Thu Dec 04, 2003 1:16 am

#13040 - sajiimori - Thu Dec 04, 2003 3:10 am

#13042 - crossraleigh - Thu Dec 04, 2003 3:26 am