#176985 - blessingta@hotmail.co.uk - Wed Nov 16, 2011 5:39 pm
hi
Where are these functions in devkitpro and what do they so?
| Code: |
SetMode(MODE_4 | BG2_ON);
//what is screen mode and why is mode_4 chosen in one of the pcx
//background examples?
//And secondly, I'm thinking BG2_ON is the background layer chosen
//(the third from the front) is this write?
|
| Code: |
DecodePCX(splash_pcx, (u16*)VRAM, PaletteBuffer);
//With this I was thinking that this was obviously the function
//used to load the data from the makefile.
//VRAM would be the OAM sprite holder used to describe how we output the stuff onto screen isn't ?
// And finally the palletebuffer is where the splash image is loaded is loaded. |
Am I on the write lines? Plus where can I find code that demonstrates various areas/ways of sprite loading?
#176989 - elhobbs - Wed Nov 16, 2011 6:46 pm
no, you do not appear to be on the right lines. This looks like a bitmap mode example. what is wrong with the examples installed with devkitpro?
#178352 - guybrushthreepwood - Wed Mar 25, 2015 5:31 am
Okay, first of all, SetMode is defined to set the value of a register to a certain value. Certain bits hold certain information and that's what the MODE_X and BGX_ON set when binary or'ed together.
Mode 3 holds the entire 240 x 160 data as 16-bit values for each pixel and stores the color directly. The disadvantage is that any changes you make are displayed right away and making large changes to the screen can result in taring.
Mode 4 holds the data as 8-bit values corresponding to a palette array of 256 colors (which can have the same depth, but you only get 256 of them). Note that you can still only write to vram 16 bits at a time so binary operators are needed. In other words, values representing 2 pixels are double-packed.
This allows mode 4 to hold 2 screens worth of data, so the concept is that you write to one side of vram which isn't currently visible, then change which side is being read from, then write to the other side, etc. This prevents taring and is called page flipping.
Mode 5 is like mode 3 but with reduced resolution. It looks bad. No one uses it.
Modes 0,1,2 are tiled modes. Whole other topic.
Hard to explain what to do until you learn how mode 4 works. I'd recommend learning tutorials. In practicality, usually tiles are used and there is learning involved in those modes as well.
#178354 - AntonioND - Wed Mar 25, 2015 7:11 pm
| guybrushthreepwood wrote: |
| Mode 5 is like mode 3 but with reduced resolution. It looks bad. No one uses it. |
That's not true, some 3D games and demos use mode 5. They scale the BG to fill the whole screen. It's a good idea to be able to draw polygons faster.
#178355 - elhobbs - Thu Mar 26, 2015 12:21 am
I assumed this post was spam as it is responding to a 4 year old thread...
#178357 - SimonB - Thu Mar 26, 2015 4:40 pm
There was a new spam post before guybrushthreepwood posted. After the spam was deleted it does indeed look like guybrushthreepwood bumped the thread...but he/she didn't :=)
Simon
#178358 - DekuTree64 - Thu Mar 26, 2015 7:55 pm
The trick to mode 5 is that the width of the usable area is equal to the height of the screen. It's designed to be rotated 90 degrees and then scaled so the pixels are doubled horizontally. Still pretty ugly, but at least it's consistent. Also has the interesting effect of making it so sequential pixels in memory go in the up/down direction rather than left/right.
You can also do basically the same style of double buffering with normal horizontal addressing, by using mode 3 and scaling so the pixels are doubled horizontally. Then only draw to one half of the screen each frame, using whichever is currently offscreen as the back buffer, and change the scroll register to "flip" :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku