Home | Forums | What's new | Resources | |
ndiddy's SGL questions |
ndiddy - Jun 11, 2018 |
ndiddy | Jun 11, 2018 | ||||
Solved the issue by moving the background to a rotating one (idk how that fixed it, it's magic i guess) Code for anyone in the future who has a similar issue:
Code:
|
mrkotfw | Jun 12, 2018 | |||
Let's try to figure out why it doesn't display under normal backgrounds. What does the *Debug/VDP2* Window say about the backgrounds? |
ndiddy | Jun 12, 2018 | |||||
Thanks for the help, but I think it's because my "memcpy" way of copying textures to VRAM didn't work as well as Sega's example code (transplanted using "CEL2VRAM" into my original code and it seems to work). If you know about SGL, I was wondering if it's possible to get semi-transparent backgrounds using it. The manual mentions semi-transparent sprites, but nothing about semi-transparent backgrounds. Also, what's the best way to get the reciprocal of a FIXED number (16.16 fixed-point)? ((1<<16)/scale)<<16 sorta works but cuts off the decimal so it's obviously not that useful (I want to do this because the background scaling parameter is the reciprocal of the scaling factor, while the sprite scaling factor is just the scaling factor so you need to take the reciprocal to scale the background along with the sprite). |
mrkotfw | Jun 16, 2018 | |||
So it works now with normal backgrounds? You'll have to actually divide it. It's no different than with floats. I believe there is some division function available to you. If you know you need the reciprocal of the scaling factor. As for transparency, you'll need multiple backgrounds, but I'm unsure what the functions in SGL would enable the hardware feature. |
ndiddy | Jun 19, 2018 | ||||
Thanks for the help, I got it working (for future reference, the division function is slDivFX). By the way, I'm having some really weird issue with my sprite handler function, where this:
Code:
works fine, but removing the slPrintFX(spriteScale, slLocate(0,6)); line makes sprites not display at all (it doesn't even send a command to VDP1). Is the compiler optimizing away the variable assignment for some reason, or is there some other issue I don't see? |
mrkotfw | Jun 27, 2018 | |||
What else have you tried? |
ndiddy | Jul 18, 2018 | |||
Found the issue a while ago, turns out that adding angles calculated by Deg2Ang (e.g. angle += Deg2Ang(10)) doesn't work (my guess is that there's a rounding error or something), so now I just store the degrees instead of the SGL angle format and do the degree to angle calculation in the sprite drawing loop, which does work. |
XL2 | Jul 18, 2018 | |||||
I just noticed that in your first post you used a 1024 CRAM mode instead of 2048 like in the other post. I think with the 1024 mode you need to store the palette in a special manner, like have the upper 2 k mirror the other 2 k of color data, but I never tried it so I could be wrong. |
ndiddy | Jul 23, 2018 | |||
Other question: is there a way to set priorities for specific sprites? I see the "slPrioritySprX" functions in SL_DEF.H but I don't know how to determine which "groups" the sprites go into, unless it literally means sprites 0-7. |
mrkotfw | Jul 24, 2018 | |||
There are 16 sprite types, and each has a set number of bits designated for priority index (into the sprite registers) and other features (in CMDCOLR). The sprite priority registers 0 to 7 are different priorities you can set to. For example, you have sprite type 0, and you set sprite register 0 to 3, and sprite register 1 to 7. By default, VDP1 will set the priority to all your primitives to 3. If in another command table, you set the right bits to index to sprite register 1, that command table will have a priority of 7. Confusing? Needlessly complicated? Flexible and useful? Yes, yes, no. |
ndiddy | Jul 24, 2018 | |||||
Essentially what I'm trying to do is use up a background layer for a transparent character (the game's running at 320x224 so it would be obvious if I simply used a mesh on the sprite), but I also want to animate certain features on that character using sprites. I know it's possible to do this with the Saturn hardware, but I'd like to keep using SGL (I'm far enough along that porting the game over to SBL or something would be a pain). With SGL, you seem to only have one command table, and add to it by giving the slDispSprite function the sprite position, SPR_ATTR structure, and angle. It looks like you can use the sprite's Z coordinate for some sorting within the sprite layer, but I don't know if you can put sprites above other layers using it. |
XL2 | Jul 24, 2018 | |||||
it's in your attribute color that you can set the priority. Make sure you are using color bank sprites. Try something (pseudo code) such as : Sint32 v = dist >> 24; //Just one example, if you distance is in fixed point format. if (v>7) v=7; else if (v<0) v=0; for (i=0; i { curPol->attbl.colno &= (~(7<<11)); curPol->attbl.colno |= (v<<11); } Edit : that modifies your color calculation ratio. Depending on your sprite type, just flip the priority bit. Say bit 14 then you could just flip it so that your sprite becomes sprite 1, which is registered as having priority 3. If your color calculation condition is <= 4, then your will have transparency. |
vbt | Nov 30, 2018 | |||
@ndiddy... any news of your game ? |
mrkotfw | Nov 30, 2018 | |||
His GitHub repo page... is here. I haven't seen activity in ~2 months. |