Author Topic: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc. Tools for development  (Read 2660 times)

touko

  • Hero Member
  • *****
  • Posts: 953
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #30 on: February 08, 2015, 09:03:06 PM »
Quote
Do you guys ever map anything in the typical I/O bank area?
No, because i use a custom version of Huc and i stay as close as possible to his scheme, i use some custom mapping when necessary,but not for I/O.

For compression your experiences are great, i'am a big noob for now and my first step was with LZ4 .. :wink:
I have already experienced an easy scheme for PCM samples,the packed pixel, this is not the best compression ever but very well suited for 5 bit pcm, it allow you to encode your samples in 2 bytes rather of three .
My PCM routine is 30/50 cycles / PCM with compression and mapping .It's a simple PCM playback with volume setting.
« Last Edit: February 08, 2015, 09:16:04 PM by touko »

elmer

  • Hero Member
  • *****
  • Posts: 2148
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #31 on: February 09, 2015, 03:18:03 AM »
My first Amiga games used Huffman-encoded LZSS as the article suggests, but it was a bit slow and also a pain because you had to include the Huffman table along with the compressed data.

Whoops ... I checked the source code and apparently I was having a bit of a "Brian Williams" moment with my memory!

One Amiga game was pure Huffman compressed, then LZW for a Gameboy game, then SWD for later games.

Anyway, the SWD source should be on github today and I'll send you both links.

Please forgive it's crusty old style, lack of documentation, and general limits ... remember that it was written for internal use and not for public use.

I'd be really interested to hear how it does on *your* specific data in comparison to LZ4.
« Last Edit: February 09, 2015, 04:23:27 AM by elmer »

touko

  • Hero Member
  • *****
  • Posts: 953
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #32 on: February 09, 2015, 04:05:57 AM »
Quote
Please forgive it's crusty old style, lack of documentation, and general limits ... remember that it was written for internal use and not for public use.
Thanks a lot ..

Quote
I'd be really interested to hear how it does on *your* specific data in comparison to LZ4.
No problem  :wink:

elmer

  • Hero Member
  • *****
  • Posts: 2148
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #33 on: February 09, 2015, 06:25:21 AM »
Being able to read and write to vram during active display is pretty nice IMO. It might not have a fast local to vram DMA like the SNES and Genesis, but in a good amount of cases open vram access can balance that out.
IMHO it's a HUGE win for the PCE! From my memory, the limits on the SNES and Genesis DMA were really annoying.

Yes, they can transfer a lot more in the vblank period than the PCE can ... but the vblank period is short, and the PCE can catch up and far outstrip them during the frame itself.

Doing any more complex scatter-gather copying to VRAM should be a huge win on the PCE compared to the SNES/Genesis.

Quote
On a related note.. (source code layout optimization?)
Your experience on this platform is so much greater than mine, so you're the expert.

Your thinking makes a lot of sense ... especially for anything written in assembler.

In my very personal opinion,  assembler is the only sensible language for this platform, but then, everyone is entitled to their own opinion, so YMMV.

I'll only be able to really say anything useful after I've gotten some more experience.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #34 on: February 09, 2015, 10:06:56 AM »
Using C for PC Engine is acceptable, given the right game.   

For speed you need assembly.   Atlantean only optimized what was needed to gain speed.   Some functions are still 100% C.

No point causing brain damage where it isn't needed.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

elmer

  • Hero Member
  • *****
  • Posts: 2148
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #35 on: February 09, 2015, 11:19:52 AM »
For speed you need assembly.   Atlantean only optimized what was needed to gain speed.

Wise words ... basically don't over-optimize, and don't fret over what isn't a blockage.

No point causing brain damage where it isn't needed.


Some of us don't define assembly language (particularly with a good macro assembler), as causing brain damage. As I said before ... everyone has their own (entirely valid) opinion of what is in their comfort-zone.

For your entertainment, here are 2 interesting posts by Mick West (one of the founders of Neversoft) about game programming in 1991 and 1995 ...

My coding practices in 1991:
http://cowboyprogramming.com/2008/11/15/my-coding-practices-in-1991/

1995 Programming on the Sega Saturn:
http://cowboyprogramming.com/2010/06/03/1995-programming-on-the-sega-saturn/
« Last Edit: February 09, 2015, 11:22:06 AM by elmer »

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #36 on: February 09, 2015, 11:34:52 AM »
Quote
In my very personal opinion,  assembler is the only sensible language for this platform, but then, everyone is entitled to their own opinion, so YMMV.

Considering there's practically zero advantage of using C vs ASM for 65x stuffs, I just stick with ASM. When I need to write fast working code (prototyping), I just use an advance set of macros that simulate a more advance processor  - like the 68k (makes the source code very compact, with much easier readability). And re-write stuff as needed for speed, etc.

 Still, I think it would be kind of cool to have a C directive for an assembler. Of course, one could just write an external preprocessor app to parse the source code and hand that off to something like CC65, then put the 'assembly' result back into the .S file, and assemble. Thus, C prototyping support for assembly.

« Last Edit: February 09, 2015, 11:36:56 AM by Bonknuts »

elmer

  • Hero Member
  • *****
  • Posts: 2148
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #37 on: February 09, 2015, 11:48:04 AM »
Of course, one could just write an external preprocessor app to parse the source code and hand that off to something like CC65, then put the 'assembly' result back into the .S file, and assemble. Thus, C prototyping support for assembly.

I'm looking forward to setting up a full PCE CC65 build environment (mainly for the assembler), as soon as I finish messing around trying to get GCC for the PC-FX's V810 a lot more up-to-date than it currently is.

touko

  • Hero Member
  • *****
  • Posts: 953
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #38 on: February 09, 2015, 08:00:17 PM »
@elmer:
Quote
I wrote this in 1991, when I was writing Amiga and Atari ST games for Ocean Software in Manchester, UK. I think at the time I was working on Parasol Stars. Itís an interesting look at a simpler time in games programming.
Respect ...  :shock:

And you're right, the match bytes part is bytes and not byte  :wink:

Quote
Considering there's practically zero advantage of using C vs ASM for 65x stuffs, I just stick with ASM.
Same here, i don't use C at all, now i 'am faster with ASM than C and my code is directly optimised ..
« Last Edit: February 09, 2015, 09:31:27 PM by touko »

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #39 on: March 11, 2015, 10:21:56 AM »
Phase lock/syncing the cpu with the VDC. I have some mid scanline effects that would lend themselves better if the cpu was in sync with the VDC (it's not, because of the instruction its execution during the VDC interrupt call).

 I remember something about a part in the hsync area, where the VDC is busy fetching all sprite pixels for the current scanline to draw. This is a very short period, but if write or read vram during this phase - that the cpu will be stalled. VDC regs don't count; it has to be vram. Now, I also remember hearing that this is also variable, because the sprite pixels per scanline can also be variable.

 I have an idea that might work. I do know that the VDC doesn't care if the sprite is 'on screen' or offscreen when parsing for the horizontal line. In other words, off screen sprites will also have their pixel data fetched until the 64word pixel buffer is full (which is why you should hide/clip sprites with the Y reg and not the X reg). I thinking that you could put a bunch of extra sprites offscreen, that come after your normal displayed sprites. In other words, force-ably fill that sprite pixel buffer every scanline. Then, during the interrupt call - setup to start reading vram for a period of time. To put the cpu in that window of time where it would be stalled. When it comes out of the stall, it will be in sync with the VDC and at the same spot every scanline. The timing would be tight, but it might be doable. Most long executing instructions have a 7 cycle on the max side (besides a few). You'd have to calculate a +1 to +7 cycle index into this window.

 Basically, the idea is to get rid of jitter for mid scanline effects. Not that there is a lot you can do mid scanline, but there a handful of things ;)



Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #40 on: September 16, 2015, 05:47:56 AM »
Clipping for sprites that are larger in width of 16 pixels.

 There are only two widths available on the PCE; 16 and 32 pixel wide. Anything larger is a meta-sprite.

 On the PCE (and on nes, sms, genesis, snes), clipping is important because sprites that appear to the left or right of the screen, but are off screen, still count as the sprite overflow total.

 Think of the sprite overflow as one large 256 pixel buffer. This includes transparent pixels as well (consoles really didn't have the luxury of only including opaque pixels). So, PCE will process all 64 sprite entries every scanline, but it's the buffer that prevents all sprites to be shown on any given line.

 So, clipping is pretty easy in general. When is sprite has fully left the screen, be it right or left, you drop it from the entry list (usually set the Y coord to something outside the range, or zero out the whole entry). So the sprite (X,Y) coordinates are taken from the top-left side. If a sprite is X_coord+sprite_width <= left_border, then clip it - etc.

 The obvious reason for clipping is to reduce sprite drop, or flicker if you implement it, or something along those lines. If you look at this chart here:

You'll notice that all 32 wide sprites can be easily divided into columns of 16 pixels wide.

 Take a 32x64 sprite, for example, and notice the difference of how the 16x64 sprites can be defined. Normally, for such a large sprite, vram alignment is every 0x200words. If you use a "cell offset" that falls in the middle, those lower bits of the offset are clipped to force align to a 0x200word alignment in vram.

 If you look at the 16x64 column specifications there, you'll see that can chose which column to address. It basically halves the 32x64 sprite into two columns. This makes clipping not only easy, but you don't need to have two copies of the same sprite... or always use 16x64 wide configuration.

 So for left side clipping, you'd check (X_coord+$10) <= Left_limit. If so true, then clear X_width bit in the sprite attribute entry (bit #7, which sets the width), add $10 to X_coord, and set bit #1 of the Cell_Offset/sprite_num entry (not bit #0). Right side clipping is even easier; check (X_coord+$10) >= Right_limit, then clear X_width bit. For right side clipping, you don't need to reposition the X value to compensate, nor do you need to point to the next column.

    You can't clip any tighter than that. Something to keep in mind, though, is that the 256 pixel buffer is fixed in size. If you make the screen size smaller - that buffer size stays the same. So a 256 pixel wide screen has a 1:1 ratio to the buffer. You couldn't make a huge sprite layer/image scroll from left to right, because at certain points it would need 17 sprite cells (16pixels wide) to fill the edges. 17x16 = 272 which is greater than 256. But, PCE is extremely flexible on how you define the visible display area of the video frame. If you set the display to 240 pixels wide, that's 15 sprite cells wide. The widest scroll point of cells would be 16, not 17, and thus you could do a seamless scroll of a huge sprite (given the tight clipping I showed above). 240 pixels really isn't that noticeable from 256; some SNES games ran with this size clipped window. Now, imagine a "tate" mode vertical shmup. You could set the width to something 192 pixels wide, and fake some decent looking BG layer effects. Imagine this idea taken to the SGX? Imagine how many individual moving layers you could fake.

 Or take another approach. You could make a game like Sonic, here the character is 32 pixels wide, and have the screen res clipped to something like 224 wide and clipped the vertical width with a larger display box (to make the screen area appear wider and less square). Besides a couple of key issues, you could basically create a whole BG layer of sprites.

elmer

  • Hero Member
  • *****
  • Posts: 2148
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #41 on: September 24, 2015, 05:34:13 PM »
Or take another approach. You could make a game like Sonic, here the character is 32 pixels wide, and have the screen res clipped to something like 224 wide and clipped the vertical width with a larger display box (to make the screen area appear wider and less square). Besides a couple of key issues, you could basically create a whole BG layer of sprites.

I don't know why I missed this when you posted it a week ago, but nice explanation and what a great idea!  :D

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #42 on: September 25, 2015, 01:23:31 AM »
I had worked out a system with a sprite layer/map that used 32x64 entries. Of course, these were meta-tile entries for a look-up table into segments of sprites, etc. But optimization was such that you could use the 32x64 sprite sizes for larger areas. In other words, cut down on the SATB usage. Have a 32x64 metatile setup would also mean less work for the cpu compared to 32x32. The cpu overhead is going to be greater than that of a tilemap, but it's still doable.

 Take a 224x192 screen (playable area, status bar can fill the rest if needed). In terms of 32x32 sprites, that's 7x6 area. So that's 42 sprite entries. That's also assuming a full solid screen of sprites, which isn't really what I had in mind. So it would actually be lower than that. And of course, might not want to use 32x32 segments, but maybe 16x16/32x16/16x32 here and there. So then the number does go back up. So I figured even if you get close to mid 50's, that's plenty enough left over for a platformer given the large sizes PCE can through out there. If done right, it could come off looking pretty good.

 Like I said, there would definitely have to be some limitations as to what the character can move over/walk through. For instance, Chemical Plant (level 2 in Sonic 2) is easy to do with this setup. But Emerald Hill (first level) presents some problems as the main character is able to walk through/over the foreground area in some parts (busting the sprite limit). It would need a further clipped screen of 216 wide to handle that, or add gaps in the map area to alleviate sprite congestion for those scanlines where the main character would be. So it has some design limitations. Heh, you could get crazy and make such areas lower color count sprites and manually composite the main character each frame against that area. Might be doable at 60fps. But definitely at 30fps.

TailChao

  • Full Member
  • ***
  • Posts: 156
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #43 on: September 25, 2015, 07:09:17 AM »
Think of the sprite overflow as one large 256 pixel buffer. This includes transparent pixels as well (consoles really didn't have the luxury of only including opaque pixels). So, PCE will process all 64 sprite entries every scanline, but it's the buffer that prevents all sprites to be shown on any given line.
I've wondered for quite some time if Hudson designed the sprite system on the PCE closer to the NES (which uses eight shift registers for each sprite on a line) rather than the SNES or Genesis which have true linebuffers. That would make more sense given the multiple resolutions.

You'll notice that all 32 wide sprites can be easily divided into columns of 16 pixels wide.
This is such good design, and makes it so easy to split 32px wide sprites into 16px columns when they near the screen edges.

touko

  • Hero Member
  • *****
  • Posts: 953
Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.
« Reply #44 on: October 05, 2015, 10:44:02 PM »
i have an idea for reodering sprites in a browler for exemple .
You put a copy in VRAM of your actual SATB with DMA (VRAM->VRAM) each frame (you have 2 SATB in VRAM,the real one, and a copy) .
You sort your sprites and make a DMA list of eaches sprites to copy from your false SATB to your real one .
It's free and really fast,even more if you put the VDC in 10.74 mhz mode.
If the 1 frame delay is a problem, you can change the DMA mode (VRAM SATB -> VDC SATB) from auto to manualy, and doing it when all VRAM DMA are complete .
I  already have a DMA list driven by interrupts, i'll just have to do the sorting routine .
« Last Edit: October 05, 2015, 11:18:12 PM by touko »