OKay, okay. One at a time
I was unsuccessful when attempting to get it to scroll vertically...The image just kept repeating after the first screen.
look at ...doc/Huc/clibref.txt. There is a function set_screen_size(char size) that changes the size of the -virtual- screen (not the displayed screen). The scroll function uses the size of the virtual screen for scrolling, iirc. And of course, the default value is 32 tiles wide, to match what you see. Change it and you should be able to do a 512 pixel (64 tile) scroll quite easily.
When we did PP, I -think- I used a 64x64 tile screen.
I realized that set_tile_data(leveltiles); is supposed to get three parameters if #incchr_ex is not used but I couldn't get it to compile correctly.
...set_tile_data(leveltiles, 64, 1);....
The third parameter is a char *, which is an address. try set_tile_data( leveltiles, 64, levelpal0 ) and see if that works.
At a quick glance this function appears to use ints so I figured certain variables could be modified to be chars and that would optimize the function a little bit but I fear the real optimization comes from using different function calls. The entire function is based on function calls so this would mean using different more efficient function calls to create a sprite?
Using chars as parameters only sorta works. The get pushed as ints anyway.
The real optimization actually comes from not using parameters to spr_make(). If you are using a constant in the call, move it into spr_make() and get rid of the parameter. Most of the values passed in are not going to change, so making them constants speeds things up....
If you really want to know, here's how I believe it works:
When you call spr_make(), all of the parameters get pushed onto the 'C' stack. That's not the same as the hardware stack - in fact it's pretty in-efficient if you look at the assembler code.
Then, in order to pass them along to the functions inside of spr_make(), they have to
1) Be read from the 'C' stack - that code is slow as well
2) Be pushed back onto the 'C' stack, so the functions can find them.
If you move the actual constants or global variable inside spr_make(), you avoid the overhead of pushing the arguements for the call, and the reading from the stack just to push them again.
I would like to have a top score displayed at the top of the screen. I noticed when my background scrolls so does my text!?
Yep. You need more than 1 scroll area: one for the unmoving text, and one for the moving part of the map. Luckily you can have up to 4 scroll areas.
BUT there's a catch: Everything goes in the BAT for display. So when you load your map, you have to make sure you leave the text area alone.
The more you think you kno the more you don't know.
We were all beginners at this once. Tackle one problem at a time. Before you know it, all this stuff will be if not easy, at least more understood
