Since you mentioned paletted lighting, I've always wondered, how do colors work on the Saturn? Hardware specs all say it's 15-bit RGB (32,768 colors), but when it comes to palettes, does that mean you've got 32,768 contiguous indices, or are graphics split up into 256-color banks, sort of like how the Neo Geo handled it? Can you do color cycling with more than 256 colors? Can you do color cycling on textured polygons?
You can use either 15 bits colors (VDP1, but you can also use 16 colors lookup table) or use the VDP2 color RAM (4 KB only, so max 2048 colors). With CRAM, for sprites, you can use 4 bpp or 8 bpp modes. It also means that the VDP2 is drawing the sprite to the framebuffer instead of the VDP1. But the only way you can do different transparency ratios (or more than 2) is by using VDP2 CRAM, which also "kills" gouraud shading (VDP1) since it's directly modifying the RGB value when writting to the framebuffer. Which also means that, thanks to a hardware "bug", you can apply gouraud shading on the palette index and send it to the VDP2 for processing. So by carefully manipulating your palettes, you can have both transparency and some gouraud shading or even bump mapping. Like take a RGB with red colors only (LSB on Saturn), each increase will increase your palette index by 1. So if you are careful to not overflow, you can have gradiants. I want to use green gouraud to allow flat shading (so no gouraud shading needed, which is faster to render) for quads having 4x the same verticle normals, which means index jumps of 32 values (since green starts at bit 5). It would also allow me to interpolate the "pseudo-gouraud shading" on the 4 vertices, and it would also modify the palette's adress, allowing me to have access to some 1024 colors vs 256 with red gouraud. I have seen 2 tech demos using red gouraud - but no game ever did it AFAIK. I'm not aware of anyone ever trying it with green gouraud, so it might not even work, but in theory I think it should. Now my huge challenge is to have a CLUT (VDP1 16 colors sprites) for objects close to the screen to allow colored lightning and use CRAM for far away objects to allow transparency and basic shading. The difference in colors can be quite huge and look "off", so it's not easy.
That sounds insane, and it's exactly the sort of application that makes me so enthusiastic about indexed color- really want to see you pull that off. And thanks for the explanation!
Well, that's a start. The metal Sonic is using that gouraud bug I mentionned, while the other entities use normal gouraud shading. The level itself uses 16 colors LUT for quads close to the camera with a shift in the lookup table to create different shades. I could easily add gouraud to it. The quads further away are using a 256 color bank with also a palette shift, averaging the lightning of the 4 vertices to create smoother results even if it's just flat lightning. Use gouraud there is trickier, but I'll look it up. The green gouraud bug works on real hardware (see the metal sonic having a yellow shade when he's invincible : that's the done using green gouraud to shift one palette) and the red gouraud bug works also in the Yabause emulator, but not on SSF. Sorry for the bad filming, I was holding my cellphone between my legs as I played! http://www.youtube.com/watch?v=Solq-N_jI28
Amazing work! I played alot of the release from last year with my boys (4 & 9), and we were super excited to see the latest video. We're crossing our fingers hoping for a SAGE release that includes all the new features!
That's really nice to hear! Hopefully the split screen should keep you guys busy! I still need to fix my collision code and physics as it's not very good. And I need to improve my rendering code too - all while resisting the temptation to add more effects (these rings filling the screen hurt the CPU quite a bit in splitscreen!).
Hey X2L, on the assembler forums you mentioned that you don't yet have a capture card. I expect you'll be needing one for SAGE? I'd like to pitch in a twenty for the capture card fund, if you'll send me your paypal. Maybe a few others would like to contribute too?
Amazing job, dude! This lighting almost looks like something ripped right out of the Dreamcast version of SA1, especially in the red, volcano-y stage! The one thing I'd change presentation-wise is to make Sonic's jumping animation spin faster as you jump at higher speeds, like in the Classic games (and SA2...? I don't remember whether that was a thing in that or not.) Also, I think it'd be nice if Sonic turned incrementally when changing direction instead of just turning on a dime like that. The current animation makes the controls seem way more stiff than they actually are! Also, is 360-degree movement implemented yet, and if not, are you planning to implement it before SAGE?
If you mean loops, there is not a chance it will happen before sage. I'm working 99% of the time just trying to make this work on real hardware at decent speed, so anything else is really low in my priorities. In fact I spend very little time on the gameplay since the hardware is giving me so many headaches with its 100000 restrictions. For the turning, it's already implemented, it just depends on your current speed vector. At low speed or when the speed direction is exactly the opposite from where you were going Sonic will turn quickly, else he will turn smoothly. If you meant more like modern games, well the game is designed for a d-pad. After Sage I want to improve the analog controls to make it smoother, but right now it's mostly a d-pad thing. I will look into the jumping as I wasn't even aware of it. As for the lightning, there are 2 parts to it. One is the textures. For the Red Sand map, it's mostly Andrew75's amazing work that made it look so great, I just added some extra lights on top of that. For the other maps, it's only using my own lightning functions with flat shading. For SubCog, thanks it's really appreciated, but I will be fine, worst case scenario is that I will just use an emulator.
You mean world rotation? No, because of the way the background layers work on Saturn (you can only rotate the RBG0). While it's possible to use RBG0 with interupts to have 2 planes, it wouldn't work for splitscreen. EDIT : While we are at it. Is there anyone with a PAL console who would be willing to test the game on real hardware? I don't have a pal system, but I'm afraid my dynamic framerate code might ruin the game at 50 hrz since it's all based around the fact that SGL doesn't allow fully variable framerate (AFAIK, only with v-sync, which means when the framerate drops, it drops hard). It might even run near 50 fps on PAL consoles, but I have no way to test.
Here is a preview of the SAGE demo. I'm still looking for owners of PAL consoles to test the game on real hardware, so just PM me if you're willing to do some beta testing. http://www.youtube.com/watch?v=foMLX3Lz8fQ&lc=z22kxrhj1ljbhjrp404t1aokgyrbkeblcv5zikbzbwxwbk0h00410
I was kidding about the Mario Galazy thing! The new video is slick as hell! Amazing work. I can really see the new lighting at work in this video, especially on the Sonic model. (I kindof missed it on the previous one 'cause it was flimed on the tv.) Plus all the interative elements really bring the game to life. It's easy to imagine this evolving into a real game now.
XL2, I a saw on the assembler forums that you were talking about the Mario 64-style levels. I know you're not planning that for SAGE, but I'm intrigued at that prospect for the future, especially once you start exploring analog controls. More organic feeling levels would definitely be an impressive enhancement! I wonder though, if that would drastically change the personality of the game though. With the digital controls, it feels a bit more like Crash Bandicoot or maybe Bug!, and I think that works well with the existing level designs, whereas once you get heavily into analog controls, it starts pushing you more into Mario 64 territory... not necessarily a bad thing, but definitely a change in flavor. Do you have any thoughts on that?
Well I already had the Peach castle from Mario 64 (DS version) working in the fps demo and it worked OK. Now Sonic is much faster, so it's quite challenging physics-wise and for collision detection. Once I improve these, that kind of levels will be possible. I would just add a VDP2 3d plane and the game could support levels like in Project Condor. Once I release my level converter, anybody could just decide to mod the game as they see fit. I will also try to release my model converter at or soon after sage so that people can swap models/animations if they wish.
