 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - Bit Planes, Tiles, and VWF's |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Rom Manic                   Since: 12-18-05 From: Detroit, WHAT?! Last post: 6274 days Last view: 6274 days |
| ||
| Ok, so here's the jist of my problems. I'm using YY-CHR for opening Contra III, but for the life of me I can't understand why all the graphics I'm seeing are jibberish (Most likely compression). This was just a test, really, to see how everything worked, but this form of self learning seems to be inconclusive.
So I wanted to know how graphics are stored and viewed in a ROM. From my understanding, thats a pretty broad subject, but alas I will try to break what I need to know down. First and foremost, I have no idea what a Variable Width Font is. I understand these are better than your average fonts, but are they tiles of 8x8, 8x16, etc. or what...Fonts themselves are not hard to implement to my knowledge, but I may be wrong. Next in line is Bit Plane Graphics. Again, I have a short lack of knowledge here, but as far as I can tell from the Wikipedia article, the bits are corresponding with their Hex counterparts in some fashion. A tutorial on Partial Translations once explained it to me like so as well, but the Hex values represent a certain color. So does that mean I can edit graphics through Hex as well? And last but not least, Tiles. These in themselves are not hard to understand. Simply blocks of data roughly about 8x8 pixels, no? But that aside, I must ask how one goes about inserting new tiles at the end of a ROM. Would it involve expanding the ROM, then editing the blank tiles, or something else? |
|||
Gideon Zhi Keese   Since: 12-05-05 From: ...behind you! Boo! Last post: 6277 days Last view: 6274 days |
| ||
| Well... let's start with bitplane graphics, since that's the core of it.
Basically, a byte is made up of eight bits. In bitplane graphics (specifically 1bpp graphics) each bit of these bytes represents a pixel. If a bit is set, a pixel is displayed, If the bit is cleared, a pixel is not. In theory, yes, this means you can edit graphics in hex. You may see various "BPP" modes in tile editors. This stands for "bits per pixel." In 1BPP, you have 1 bit per pixel, so your graphics are monochrome. In 2BPP, you have two bits per pixel, so you have up to four possible combinations of on/off per pixel (on-on, off-off, on-off and off-on) so you have four possible colors (usually, one is reserved for a transparency or background.) In 4bpp, you have four bits per pixel; thus, 16 possible combinations. And so on and so forth. Tiles then are simply bytes, stacked on on top of another, so that when rendered as bitplane graphics, they make a picture. As far as fonts go, your 8x8 fonts are just that - their letters take up a single 8x8 tile each. For 8x16 fonts, they take up two 8x8 tiles per letter. For 16x16 tiles? You guessed it - four. Variable-width fonts are another story altogether; they're generally stored as 8x16 or 16x16, but when they're rendered in RAM the tiles get shifted or rotated, then are melded into a "picture" of the text via logical OR. Since nearly (?) all old systems are tile-based architectures, having something that doesn't conform to standard tile sizes either needs to be displayed as sprites or as a straight-up picture. As for the difference between variable-width and fixed width, well... what you're reading right now is most likely variable width. This, on the other hand, is probably fixed width. Notice the spacing on the characters, how the letter "i" is perceptibly thinner than something like, say, a letter b or a letter g. Then look at the fixed-width text in the code tag - the "i" takes up exactly the same amount of screen space as any other letter. VWF code is... messy. It's a lot easier to write something that simply stores the full font in RAM and updates the on-screen tilemap than it is to do all of the bitlogic required of other font routines. You can drop a variable-width font on top of a fixed-width font, sure, but it'll come out looking weird unless the code is properly in place. For an illustrated example... 
Compare the printout of the name Gideon at the top of the status screen (where VWF -has- been implemented) to the printout in the quick status bar at the bottom (where it hasn't been implemented yet.) This code is for a 16x16 VWF - it accepts characters up to and including a possibly 16 width, so the font itself is stored as 16x16 tiles. Without the VWF code, it still displays as 16x16 tiles, and looks rather ugly in comparison to the rest of it. |
|||
|
Rom Manic Since: 12-18-05 From: Detroit, WHAT?! Last post: 6274 days Last view: 6274 days |
| ||
| *Rom Manic checks off few boxes on his clipboard, and gazes at Gideon's peformance.
Your helpfulness won't be forgotten, Gideon. I'll make sure of it. And yes, it took me this long to think of something semi-funny to say  |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Bit Planes, Tiles, and VWF's |
| |
