|
Post by lunchbox on Dec 6, 2018 2:22:20 GMT
Im just toying around with huC and finding that when I print text at the very bottom of the screen and then attempt to scroll window 0, I get some odd things happening. Window 0 is not touching the area where the text is printed and yet when I use the scroll function to scroll window 0 I end up scrolling the text as well somehow. Doesn't seem to matter if its horizontal or vertical. Anyone have any ideas or tips?
|
|
|
Post by gredler on Dec 6, 2018 16:44:24 GMT
Im just toying around with huC and finding that when I print text at the very bottom of the screen and then attempt to scroll window 0, I get some odd things happening. Window 0 is not touching the area where the text is printed and yet when I use the scroll function to scroll window 0 I end up scrolling the text as well somehow. Doesn't seem to matter if its horizontal or vertical. Anyone have any ideas or tips? Welcome! Glad to hear someone new trying this stuff out. It's difficult to help troubleshoot your issue without seeing your code and or a screenshot/video of the issue. Do you mind posting more info? I'm probably the last person to help but I was able to get through the obeybrew tuts so maybe I can, but I would need to see the code at least good luck getting over the hurdle!
|
|
|
Post by lunchbox on Dec 6, 2018 19:27:31 GMT
Thanks for the response! Yeah i guess I should have posted some code, however tbh i'm just screwing around and printing something and then calling a scroll command in an infinite loop with a delay really nothing fancy at all and honestly not even worth posting. I guess maybe I don't have a good understanding of how layers and backgrounds work on the pc-engine or maybe i'm just missing docs to reference for HuC? From my understanding (correct me if i'm wrong) the pc-engine has a single background layer and 4 configurable graphic windows? Do the 4 windows each make up a part of the single background layer? Can i have say a background as its own thing and then a screen buffer for purely text that is its own window? Really my goal I guess would be to have the screen split in half horizontally and print text to the top portion and scroll that portion vertically while NOT scrolling the lower half of the screen and still being able to write text to that lower portion separately. Seems like it should be easily doable. From my limited testing it seems that when you print text to the screen in huC that it prints it directly onto the background layer and then it becomes a permanent part of that layer and there is no way to target WHERE you want to print the text other than the background layer. Also are you supposed to be able to set the windows to point to a different graphical source to show data? I feel like either i missed that or it doesnt exist....
|
|
|
Post by theoldman on Dec 6, 2018 20:11:03 GMT
Correct. This is where your problem is. You can have 4 different viewable areas of the background layer visible at once. They are -not- seperate 'windows'. That depends on how you divide the background layer up. Not really. They will always show a portion of the background layer. ...................................................................................... Definately do-able, but maybe not obvious. Let's assume you want 2 areas; Y=(0,120) and Y=(121-239). The upper part holds static text; the lower part holds text that 'scrolls'. Now, set up 2 scroll regions (You need to provide a complete displays worth of data). They match the areas. If you scroll the bottom area and leave the top alone, it's fine..... Until the bottom area starts to wrap, at which point you see text from the top area twice. This is more obvious if you swap the 2 scroll areas. They way I think of it is that each scroll area is like a clear plastic sheet on a larger piece of paper; You only see on the screen what is underneath the plastic.
|
|
|
Post by dshadoff on Dec 6, 2018 20:57:55 GMT
Another comment is that text scrolling probably shouldn't be thought of as 'scrolling' in the same way as, say, a background map. You probably don't want a text buffer beyond what is visible.
In its simplest form, text scrolling (especially in the days older than the PC Engine) was "copying stuff upward". While I wouldn't actually implement this in C (because of speed), it would be something like:
For (line = 1; line < window_size; line++) { copy_line(line-1, line); /* destination, source */ } blank_line(window_size-1);
... where copy_line just copies the contents of one line into a different line, and blank_line put spaces into the target line. The first line is covered over, and the last line is blanked out; everything else moves up a line.
Dave
|
|
|
Post by elmer on Dec 6, 2018 22:07:57 GMT
They way I think of it is that each scroll area is like a clear plastic sheet on a larger piece of paper; You only see on the screen what is underneath the plastic. That's a really nice analogy. I guess maybe I don't have a good understanding of how layers and backgrounds work on the pc-engine or maybe i'm just missing docs to reference for HuC? From my understanding (correct me if i'm wrong) the pc-engine has a single background layer and 4 configurable graphic windows? Do the 4 windows each make up a part of the single background layer? Can i have say a background as its own thing and then a screen buffer for purely text that is its own window? You are confusing the PCE's basic hardware capabilities (the single background layer), with HuC's software library routines, which sorta-kinda allow you to change which part of that hardware background layer that is displayed, at various points part way down the screen ... what HuC calls "windows". The background layer can (optionally) be much larger than a single TV screen, in order to make scrolling somewhat easier to program ... but there is still only that one single layer. The PCE hardware lets you change what part of the background layer is displayed on every single scanline, if you wish to, by using interrupts to change the X and Y scroll registers. HuC uses that mechanism to provide its 4 "windows", but the number "4" is a HuC limit, and not a hardware limit. This is exactly the same capability that the SNES and Megadrive allow, although the SNES does it with DMA, rather than interrupts. Does that help? BTW ... have you looked at the hardware docs yet? A link to them can be found in my stickied thread in this section of the forum. If you are comfortable with assembly language, then you can just skip using HuC entirely and so get around its limits ... or you can write your own low-level assembly functions and call them from Huc. But, if you just want a single-screen-wide section that only scrolls vertically, and a single-screen-wide section that is static, then ... ... just use a 64x32 tile background layer, then draw the scrolling part on the left 32x32 section of the layer, and draw the static part on the right 32x32 section of the layer, and use HuC's "windows" to display the different sections on different parts of the physical TV display.
|
|
|
Post by lunchbox on Dec 7, 2018 15:45:14 GMT
I get the concept of windows. Im familiar from doing a bit of coding on atari platforms that have something similar and the genesis. Is there an entire listing of all the possible functions other than whats listed in clibref.txt in the huC folder structure, or is this all there is?
|
|
|
Post by elmer on Dec 8, 2018 4:54:38 GMT
I don't know of any other function list, but then again, I don't actually use HuC.
You can find all of the source code to the library in the huc/include/pce/ directory ... perhaps you'll find more information in there.
|
|
|
Post by Arkhan on Dec 19, 2018 20:31:08 GMT
Do you have an example of what you were doing?
In my head it sounds like you're scrolling the BAT around in your various regions, and it's wrapping (moving the text) in ways that it would due to how it functions... even though it isn't what you want to happen.
and yes, printing text means you've modified the background permanently. Those tiles where you print to will now scroll with text on them.
|
|