The Lord of King 🇧🇷

#PCエンジン #pcengine #tg16 #retrogaming #rondo #draculax #castlevania #retrodev Time to show some progress on this PC-Engine Dracula-X demo that has been over a year now in coding development. The fire effect and most of the foreground sprites were done a while ago. All these little things to make it feel like a game now, and not just a graphics demo.. way too much time. It's the little things that are time sinks. This still isn't the final version - need some more polishing. I ended up doing more than I had originally planned.. and having more detail and things that were originally not calculated for. Yes, this is a PC-Engine.. no graphic chips or SuperGrafx here. But I did end up using more LUTs for the added detail, and expanded beyond my memory budget (512k CD RAM). I'm converting it over to Arcade Card for the required memory budget and to just make things a lot easier on me hahah. Some interesting things here; the translucent fire layer and house layer take up the LEAST amount of CPU resource here. To the point where I would have so much cpu resource left, that I wouldn't know what else to do with it. But see that large wall section with the stairs? THAT part eats up soo much CPU resource. Part of that is my own fault because I wanted more detail than I had planned for that part (and I made the sin-wave effect more aggressive than it was supposed to be). You see how the background has all that sin-wave effects? The foreground in that large wall section.. is dynamically counter acting every single offset! I'm not gonna lie.. the idea is a little crazy. I'll post a video showing the tilemap section in a reply. On average, the cpu cost is like 55%.. but heavy areas like this average 70%.. and heavy spikes as much as 90% cpu usage! But it's still a rock solid 60fps. Anyway.. this has been what.. 16 years in the making? I designed and spec'd everything you pretty much see here back in 2010. All the number crunching, total costs, design, effects.. everything you basically see here, I had already figured out back then. That's how I work.. without writing a single line of code.. I design the graphic effects and cpu costs all upfront. From there, it was just a matter of coding it up (the boring part haha). Feels good to have it in a playable state. A proof-of-concept on paper.. to a proof-of-concept in action. 3 layers of parallax, translucency, and 60fps on a 1987 "8bit" console. Not bad. FYI: If this was on the SuperGrafx.. this would be a cake-walk. By far. Maybe I'll do an upgraded SGX version too.

Yeah, PCE has three pixel resolutions; 5.37mhz, 7.16mhz, and 10.74mhz. Those are three pixels sizes. In combination with those, you can define how many pixels are active on a line - by units of 8 pixels. And finally, you can define how many lines a screen will have (up to 242 can be visible) - in units of 1 scanline. R-Type (JP) use 7.16mhz pixel dot clock and 352 active pixels on a line (out of the total 455 pixels - that includes hblank). 7.16mhz is ~139ns ram access. The vram memory on the PCE is 120ns, so it's faster. What the US version of R-Type does, is put a wait state on vram.. meaning it forces the VDC access vram twice as slow at 278ns. How that affects sprites; all sprite pixels needed for showing on the line are fetched entirely in hblank. In terms of dot clocks.. to fetch all sixteen 16 pixel wide cells, it takes 4 pixel dot clocks (all measurements/timing can be represented in pixel dot clocks) per 4bit 16 pixel wide sell. So you need a total of 64 dot clock pixels to fetch all cells. In JP R-Type, 455-352 = 103 pixels of hblank. That's more than enough. Of course, some of those dot clocks in hblank need to be setting up the line.. so you can't use all of it for sprite pixel fetching. But what happens when you put vram into 1 wait state? Vram access now becomes twice as long.. so 64 dot clocks to fetch all sprites now becomes 128 dot clocks. To give it more room, if you run that setup, you need to give it more hblank time. So the US version reduced the line down to 336 pixels active.. but that's still not enough; 455 - 336 = 119 dot clocks. You would need to drop down to 304 pixels wide to fetch all of them. 455-304 = 152 dot clocks.. and you need around ~20 more for the line prep stuffs. 336 dot clocks is not enough time.. it needs 32 more. And since vram is now running double slow, that means every 8 dot clocks to fetch a full 4bit cell.. so it 32/8 = 4 sprite cells are dropped. That means you can only have 12 sprite cells per line.. not the full 16. AND on top of ALL of this, you need to "cull" sprites. That means removing sprites from SAT (sprite table) when they are off screen, because they get included in that cell count for the line! But the US Hucard, and the JP CD version, never bothered to fix the culling.. they assume the visible part of the screen is still the original 352 pixels wide. So on top of the reduced sprite cells per line, you also have off screen sprites (on the right-hand side) potentially causing even more drop out! Other IREM games that came to the US, like Ninja Spirit and others, don't have this vram wait state enabled.. only R-Type.

Here's a better video/GIF

#PCエンジン #pcengine #tg16 #retrodev #retrogaming #shmup #bullethell I very much like shumps/STG/shooters, but I'm not into bullet-hell ones. They just never clicked with me. And from the dev side of things, the PCE/SGX doesn't have hundreds of sprites - at least, not natively so it wasn't really an interest for me on that side either. But a while back @upsilandre had a video showing collisions for the 2nd ship level/boss in R-Type for PCE. And how it got up to around 400-700 total collision checks. I mean, it slowed down but I thought that was kind of impressive for an early title. So I figured.. just from the CPU side of things, how many collision check can the PCE do? I had a pretty good idea but never put it to the test. So, time to do it. Now, I knew of some of the tricks used BITD for bullet-hell shmups/STGs. Or, at least I have heard some. Single points for bullets (instead of boxes).. and grids, etc. Everyone always talks about collision detection like it's the most taxing thing.. but "transforms" cost more! Still, I read that early Cave shooters like DoDonPachi actually cheat (because the bullets move slowly, they split the collision check for the bullets down the middle across two frames). And I do know of some console games that also cheat like this. No cheating here. Just smart code and pure cpu grunt. What you're looking at here in these videos is 800 bullets, 1 player ship, 32 enemies, and 16 player shots. That's 1344 total collision checks. No grid system here. And that's also 800 8.8 fixed-point delta transform movements on X/Y positions, object culling at the edge of the screen.. and object spawning. The cpu handles all the collision, and all the objects, and all the transforms for the objects. The only thing here, because the original PCE VDC can't show 849 sprite objects - I have a LUA script in Mesen emulator drawing the bullets - it reads out the SAT the CPU creates. The bullets are about 5x5 in size, but they are single point collision boxes. So, the PCE cpu is doing ALL of that, and handling the 1000 entry wide SAT in ram, at ~62% cpu resource. Read that again.. it's only taking 62% cpu resource for the entire logic. And.. no grid system here. Every object is checked. You might be asking.. how is that even possible? One of the oldest tricks in the 65x arch.. LUTs. LUTs are extremely fast on the 65x arch. They are in fact one of the magic elixirs of the design. Here, I use no comparison instruction for the collision check. I use the bullet X position as an index into the player's position that is an array of 0's and 1's. LDY bull_x,x; LDA p_x,y; Beq xx. That's it's. No 4-point check either; only two checks.. X and Y, with an early opt out after failing X. Early exit on X.. is 14 cycles. And with this, I can unroll this too (it's unrolled to 32 in this video). Looking at the video: the grey bars represent the X LUT and Y LUT or arrays for the player position as well as the width/height of the player 4-point collision box. The player is the red square, and the boxes next to it are when a full bullet collision happens (I didn't bother showing anything for the other collisions). The white cross-hairs are player shots, and yellow boxes are enemies. Player shots and enemies are still 4-point checks here. To put that into perspective, DoDonPachi doesn't even put close to 800 bullets on screen.. and divides the collision up across two frames (and still uses point collision to speed things up). This 800 bullets, 1344 collision checks, 850 full object transforms (with fixed point movement), culling, spawing,etc.. all done in a single frame.. at 62% cpu resource. On an 8bit processor. "[PC-Engine] nice colors.. but it only had an 8bit processor" - You know.. some 8bits just hit different😅 Anyway, that was a fun exercise. Unless you put a special VDC on the back of a PCE.. you're not going to see these 800 bullets hahah. But hey, the CPU can handle it. Also, and no - grid'ing won't help here. Grid'ing isn't free, but that's not even the issue. The cost of collision detection on 800 bullets against the player is slightly less than 10% cpu resource (out of that 62%). The biggest cost are transforms and handling logic of those objects. Which was also kind of the point of this test (to show that - to put a figure to it). The one optimization I did here, was that when I go to do the transform on the bullet object, I also do the collision check against the player. It shaved like 5-8% cpu resource off the top. ::Just to note:: I did not use AI for this (the idea or design). It's not a good fit at this kind of stuff, and you don't need it for this either. This is just taking existing ideas that have been out there forever and adding a couple of tweaks.

#PCエンジン #pcengine #turbografx #tg16 #retrodev I hooked up a logic analyzer to the expansion port of the PCE, and captured the digital pixel bus, vsync, hsync, pixel dot clock, etc. I was writing test roms for RE'ing stuff. Just to note, these Vsync and Hsync signals are the ones that drive the VDC for syncing it.. not the external sync signals (composite sync). They are sent from the VCE tho. The cool thing is, if you know the color table contents, you can re-construct a visual image from the collected data. Here's an example Bonk demo. Not only the visual pixels, but I can overlay the hsync and vsync signals, and VDC interrupts.. in exact phase to the pixels being rendered. A lot like the Event viewer in Mesen emulator/debugger. So the yellow pixels are the VDC vector reads for the cpu interrupts. Basically, those are line interrupts and you can see when they're firing and the moment the cpu acts on them. And because there is a BG/SPRITE bit on the digital pixel bus, I can also separate BG pixels from Sprite pixels. Better than a capture card hahah. I can overlay whatever signals I want too - given I have enough pins on the logic analyzer.