Graphic, Sound, & Coding Tips / Tricks / Effects / Etc. Tools for development

[Bonknuts]

Can we get a sticky for graphic, sound, and coding tips/tricks/effects/etc?

 Since the TED info isn't stickied, here are the relative links for it:
http://www.pcenginefx.com/forums/index.php?topic=21121.0
http://www.pcenginefx.com/forums/index.php?topic=20120.msg436168#msg436168


TOOLS

 http://tasvideos.org/Bizhawk.html Bizhawk PCE emulator with LUA script support. Perfect for debugging your games, or hacking exiting games. Check out the sample LUA script for Neutopia. It shows collision boxes and HP points for them.

[Necromancer]

Done.

[Bonknuts]

Thanks

 Saw this article on Contra for NES: http://tomorrowcorporation.com/posts/retro-game-internals-contra-collision-detection

 7 part in depth look at Contra and the engine is runs on. One interesting note, is how collision detection is used for object to object. The main character is a single point and all other objects are boxes. The bullets are considered 'spawned' enemies. The collision box for the enemies change depending on the mode the character is in (laying down, standing/running, and jumping). I don't think it saves a whole lot on cycles, but interesting approach none the less.

[touko]

Very interesting, and useful .
I think maybe a box for player caracter and an unique point for enemies bullets can save some cycles .

I have a very generic box collision detection routine (it works for all type of games), it takes 192 cycles if collision between 2 sprites occur,this is not the fastest routine ever but not slow .
I think in a real use it takes between 5000 and 10000 cycles for a fairly good amount of check like needed in a shmup,in my case 10000 cycles is 50 effective collisions at same time in a frame .

[Bonknuts]

10k cycles isn't bad at all. That's only 8.3% cpu resource for the frame. The PCE could easily handle double that if the VDC could handle it without flickering. A shame really.

 Touko, do you have a game engine that handles object to map collision... for slopes? Maybe something along the lines of Sonic or Mario?

[touko]

Touko, do you have a game engine that handles object to map collision... for slopes? Maybe something along the lines of Sonic or Mario?

Yes i have, it's (for now) 200 cycles for testing a 32x16 sprites with bg tiles, i tested this routine for flappy bird SGX ..
The slow part is to translate the player's coordinates X/Y in tiles coordinates,and after i test directly in VRAM with auto incrementation, it's fast and easy i think,and better if you have a dynamic TILEMAP .

But it's easy to do more faster, test only some points,for exemple no need to test an entire 32 pixels wide sprite if player go forward, or backward ,same for each direction .
For testing, with flappy i test the entire player's sprite .

The PCE could easily handle double that if the VDC could handle it without flickering. A shame really.

Yes of course, even with my routine you can test more collisions without impacting to much the cpu  .
You can easily improve performance with caculating each boxes in a RAM array when you move each sprites, this is not the case actualy with my routine .

And like you, i have some SGX games in mind 

[Bonknuts]

I had something I wanted to show off on the PCE, but I don't have a slope collision engine (only block tiles/physics and collision).

[touko]

but I don't have a slope collision engine

same here,my routine is only for shmups, not for plateformers .

[Bonknuts]

Maybe someone from the NESdev scene has something I can borrow/use.

[touko]

For now, no need for me to have a complex objetc/map collision routine, my next project will be a shmup and perhaps a browler . ;-)

[Bonknuts]

Expanded color palette mode on the PCE/SGX

 This specific effect only works on composite (or RF) of the original consoles: no RGB or s-video mod.
This is based on the same effect as CGA composite artifacts, and is specific to NTSC signal only.

 Since the mid res mode (7.159mhz) is double the color burst frequency, you get direct artifacting between two signals ( Y and C). The trick here, is to turn off the PCE's XOR color burst alternating bit (this bit removes the artifact for still/non moving screens).

 Two things to consider:
1) The color burst is still XOR going down the screen, but just that it doesn't swap on the next frame. Your dithering will have to compensate for this (pretty sure vertical line dithering doesn't work for this, so XOR checker board dithering is needed).
2) I haven't found a way to directly control which 'phase' you are in, on start up (two phases: blue slightly cool tinted or slightly warm tinted). IIRC, you can switch/change the phase by enabling and then disabling the XOR pattern bit on the VCE for a single frame. So this requires user input from a visual aid, so the program will know (exactly like the Coco 1/2 red/blue mode, except you don't need to reset the console).

 Unlike Genesis dithering (in either res mode), this appears thoroughly solid. 

 So you get more colors per tile, for averaging dithered 16 colors, and you get colors outside the default 512 master palette. Limited, but a cool effect. Could be great for doing a raycast style engine (since the screen doesn't scroll), or some other demo effect.

[touko]

I have a question in mind, it's feasible to do self modifying code on AC
Or simply execute some code on it

I ask this because i want use some compiled sprites for my browler.

[Bonknuts]

You mean like ST1/ST2 opcodes executing sequentially from AC ports (the 8k $40-43 banked ports)?

 In theory it should work, but in practice it'll mostly likely lock up. The arcade card has no way of stalling the cpu (with /RDY), and AFAIK - it buffers (reads ahead) from the port for the next value after the first it read (or written). At minimum, that's like 6 cycles per byte on (Txx), which I think is fast enough for any type of sequential or random access of the memory through the ports (it's fast DRAM, but it's still DRAM with a refresh cycle hidden in there), but when you execute sequential code from the 8k banked ports - it hits that port on every cycle of the instruction (1cycle per byte), instead of 6 or 10 or whatever cycles per byte. I almost positive that's too fast (120ns for byte access on the PCE side. I think the dram was 70ns, but couple that with a refresh hit and I'm pretty sure you'll exceed 120ns window).

 You'd have to copy the embedded opcode/sprite data to local ram first, then execute it. Unless you mean something else..

[touko]

You mean like ST1/ST2 opcodes executing sequentially from AC ports (the 8k $40-43 banked ports)?

Yes this is that i mean .

Thanks for explanation,the fastest way is to use txx for transfering datas,and for a SGX browler it will be harder than I thought .
i think that i'll need a double sprite buffer in vram, vblank is not enough to update sprites with txx .

You'd have to copy the embedded opcode/sprite data to local ram first, then execute it. Unless you mean something else..

I think is better to copy directly in vram, doing the copy twice is not the best way(but no need a double buffer in that case)

[Bonknuts]

If it's a brawler, you could probably get away with interleaving updates on specific frame intervals. I mean, it's pretty rare that frame updates need to be 60hz for a character. Someone else had mentioned this (something like 4 frame slots, so frame/pixel animation was limited to 15fps).

 Though if it's SGX, and you're using both sprite planes from both VDCs as a single virtual/pseudo SATB (cause you need to process sprite priority layering) - then I can see where you would need to update between both VDCs at a faster rate. I.e. it's fairly dynamic as to which VDC would receive the frame update (or even need a redundant update; the character moved from VDC2 SATB to VDC1 SATB and VDC1 needs the frame that VDC2 already had in memory).

  But being a brawler, surely you could fit most enemy frames (as ST1/ST2) in local memory to keep those as fast updates. Since most of the game data is going to sit in AC ram anyway, you have lots of room for stuff in local ram. 32k of ram should be plenty for a brawler engine, and 16k of work ram (8k of that being original sys ram). That leaves you with 216k. And most brawlers break up a stage into subsections, which you could take advantage of and replace/update enemy opcode sprites in local ram (from AC ram). Same for bosses. You can use mini 'transition' scenes to hide this 'loading'. Or do it as a background process in an area that's lite on enemies. Etc.

 If you can't tell, I've thought a lot about this before (SGX+AC+brawler)