So, is there a scanline timer interrupt or a relatively accessible method of duplicating the function of one within the PCE hardware? Specifically, it would be nice to have a fixed tile area at the top or bottom of the screen that doesn't use sprites that can accommodate a playfield that can scroll in any direction, despite the playfield and the status area being comprised of tiles.
See Super Mario Bros 3 on the NES for a perfect example of this.
Is this something the PCE can replicate without too much trouble?
Are you saying you want to break the screen into various sections, one of which scrolls every direction, while another stays still?
....like the status bar on a ton of PCE games?
and Pyramid Plunder?
That effect uses background tiles and not sprites? If that's so, awesome. Question answered.
Yeah.. Atlantean does this too. The entire HUD display is just a 16 pixel tall section of the background. No sprites.
Pyramid Plunder is a 32 pixel tall section instead.
It's still all background tiles.
Good deal. That's what I wanted to know. Thanks!
Ahem.
(?action=dlattach&topic=11548&attach=7844&image)
OG: IMG_1076.JPG (https://www.chrismcovell.com/images/IMG_1076.JPG)
Of course, the PCE has a scanline timer and HSync interrupt. IIRC, Tomaitheous implemented a pretty flexible scanline scrolling system in MagicKit. Did he add it to HuC as well?
^^^ Yeah that's the demo I was looking for (in another thread). I showed it to OldMan (he was asking about it). Its wayyyyyyyyy at the end of Zeograd's homebrew listing.
I don't know if Tom added anything to HuC. I don't think he did, since he doesn't use HuC himself.
Aetherbyte's stuff has flexible scanline scrolling. It's sorta built in already to HuC. With a bit of fiddling you can get it to do what you want.
Quote from: guest on 04/11/2012, 12:26 PMSo, is there a scanline timer interrupt or a relatively accessible method of duplicating the function of one within the PCE hardware? Specifically, it would be nice to have a fixed tile area at the top or bottom of the screen that doesn't use sprites that can accommodate a playfield that can scroll in any direction, despite the playfield and the status area being comprised of tiles.
See Super Mario Bros 3 on the NES for a perfect example of this.
Is this something the PCE can replicate without too much trouble?
You've already got your answer, but contribute some more specifics.
There's an Hsync interrupt service. You tell it what 'scanline' number to generate the interrupt, and it does when it reaches that scanline. When the interrupt hits, you can change a number of registers for the display on that given scanline; scroll X position, scroll Y, position, BG on/off, sprites on/off, VCE colors, etc. You can even generate interrupts for none showing scanlines (scanlines in vblank area). If you write to the audio chip, you can use this to do 16khz samples or such updates.
I wrote a bunch of stuff for HuC (even some code for the executable too). Zeo took most of it, but it never got published afaik; SGX duplicates for all main video functions (sprite,tilemap,etc), arcade card access, some additional CD functions not on the list, some new hsync routines, long pointer access, etc. I had some of it up on my old site, but nothings posted anymore. I made something for Xavier (hsync). Not sure if he ever used it. I never used HuC for my own stuff, but I've spent a good amount of time messing around with it and the backend lib. Only a handful of people use HuC and they all seem to have their own custom stuff for it, so there's really no sense in trying to make new functions for it for the public to use (which sucks).
Quote from: TurboXray on 04/11/2012, 10:36 PMI wrote a bunch of stuff for HuC (even some code for the executable too). Zeo took most of it, but it never got published afaik; SGX duplicates for all main video functions (sprite,tilemap,etc), arcade card access, some additional CD functions not on the list, some new hsync routines, long pointer access, etc. I had some of it up on my old site, but nothings posted anymore.
Why didn't Zeo publish it?
Though, the stuff built into huc is decent enough for splitting the screen.
I'd love to dig through your old HuC stuff, Bonknuts. It sounds like you wrote some really useful stuff.
HuC can do horizontal split-screen so easily, but I wish the screen could split into more than 4 segments... ie control individual scanlines--for making wavy raster effects
QuoteWhy didn't Zeo publish it?
'Dunno.
Quote from: cabbage on 04/12/2012, 02:20 AMHuC can do horizontal split-screen so easily, but I wish the screen could split into more than 4 segments... ie control individual scanlines--for making wavy raster effects
Even if you have such control, the array support for such effect will slow you down almost to a crawl. I ran into this problem many years ago with HuC and one of the solutions was to build in support for wavy effects directly into the hsync routine. But then the problem creeps in that more flexibility makes the routine more complicated and requires more space. Doing any sort of custom hsync routine to control all scanlines is fairly easy, but you got to get around the slow array access in HuC first. Later I just made backend ASM functions for array read/write, but it never looked as clean/nice as native C code. Arkhan has a work around for this, but I don't know if it's public.
The workaround for HuC arrays is to not access them with C. Use Assembly.
You can also fuck with the HuC scrolling to add more lines, like Atlantean. There's like 8 sections, and it's still HuC
Cabbage: I found my AC+SGX lib for HuC. If you want to try it out, I can post a link to it (I have a source demo to go with it, but I should probably clean that one up).
Attached is the manual for the SGX part.
The VPC window section most likely needs a section all its own to really explain it what the parameters do.
Tom, I'm interested by your lib (XAV is also interested), because my next project should be on SGX.
And of course,manual is welcome ;-) .
Quote from: touko on 04/13/2012, 05:16 AMTom i'am interested by your lib (XAV is also interested) ,because my next project should be on SGX .
And of course,manual is welcome ;-) .
wayback://pcedev.net/HuC/sgx_ac_lib_ver_1_2.zip (https://web.archive.org/web/20141028193809id_/http://www.pcedev.net/HuC/sgx_ac_lib_ver_1_2.zip) :)
It doesn't have that custom hsync lib that I did for Xav, though.
thanks, this is very useful, and why reinvent the wheel !!!
for your custom hsync lib, is not very important for me because i have now the skills for writing my own .
But surely it would have been interesting for people who want to understand how to do their,as i did with your first one . :wink:
Quote from: cabbage on 04/12/2012, 02:20 AMI'd love to dig through your old HuC stuff, Bonknuts. It sounds like you wrote some really useful stuff.
HuC can do horizontal split-screen so easily, but I wish the screen could split into more than 4 segments... ie control individual scanlines--for making wavy raster effects
Like this? pcedev.net/HuC/Chsync_ver_1_1/chsync_ver1_1.zip
Like I mentioned before, you need ASM to support it. It's not JUST array (more specifically pointer) being slow, although it is, it's everything included and needed to modify 224 scanlines of data. That demo for HuC, 224 scanlines (doh! I clipped the display to 216 scanlines.. so I wasted some cpu cycles making scanline data that will never get used) are used for three effects: BG color #0, X, and Y regs. I didn't animate BG color #0, so it requires no maintenance in vblank. Only X and Y scroll reg arrays. And at that, I only did the LSB of the scroll regs (usually don't need more than that for wavy effects or line scrolls). The loop takes 11,200 cycles. Vblank (216 scanlines) is 20,000 cycles. So half of vblank is needed. Though if you double buffer or 'chase' the beam, you can update during active display without artifacts and give more time back to vblank sensitive code.
Equivalent C code would be:
sin1_idx=old_idx1++;
sin2_idx=old_idx2++;
for(j=1;j<224;j++)
{ hs_x_l[j]=sin1[sin1_idx++]; hs_y_l[j]=sin1[sin2_idx++]+j; }
J is a char, although that won't matter much here if it was an int. It takes the above C code 217,729 cpu cycles to complete that loop! 11,200cycles VS 217,729cycles. Hell, a single 1/60 frame is only ~119,436cycles.
Edit: Opps, sorry. I had the 'master' cycle count in there instead of cpu cycle count for C code. Fixed. Also fixed link.
Neutopia 2 does the wavy screen effect during the first minute of the game.
Racing games like Victory Run use the same kind of effect to draw the track.
You can set the RCR register to fire an interrupt on any scanline you like, as many times as you want.
Bomberman '93 does a vertical one for the underwater stages. I always thought those looked nice.
Doesn't Neutopia II do this for the underwater areas over the entire screen?