#747 - darkcloud - Fri Jan 10, 2003 5:26 am
How would you make a sprite "flash"? You know, like when a character in a game gets hit by an enemy, usually they'll have a time of invincibilty to recover from the hit. During this time, the character will usually flash to denote the hit. I was wondering how to get this effect with my sprites.
_________________
Maybe in order to understand mankind, we have to look at the word itself: "Mankind". Basically, it's made up of two separate words - "mank" and "ind". What do these words mean ? It's a mystery, and that's why so is mankind.
#749 - Splam - Fri Jan 10, 2003 5:36 am
Simple way, turn them off for a frame, back on for the next frame, off again etc etc
#757 - I.C.E - Fri Jan 10, 2003 10:09 am
For an other flashing effect you can also set the palette of the sprite to another color for one frame and then set the original back again for a period of time.
#758 - Splam - Fri Jan 10, 2003 11:37 am
But, then each sprite would need a specific palette entry for the "flash" colour. Fine if its only a couple of sprites, not so fine if it's for hundreds of enemy sprites or something.
#905 - subbie - Sun Jan 12, 2003 1:01 am
| Splam wrote: |
| Simple way, turn them off for a frame, back on for the next frame, off again etc etc |
I would keep them off for more then 1 frame. If you turn it on and off each frame you create an interlace effect (every other scanline will draw, also this is only seen on hardware and not emulation).
I would say a quick way to do it is if you keep your players information stored in a seperate structure just move the sprites X location off the screen for 2-4 frames then restore it back to where it should be for 2-4 frames.
#925 - Splam - Sun Jan 12, 2003 1:35 pm
| subbie wrote: |
| Splam wrote: | | Simple way, turn them off for a frame, back on for the next frame, off again etc etc |
I would keep them off for more then 1 frame. If you turn it on and off each frame you create an interlace effect (every other scanline will draw, also this is only seen on hardware and not emulation).
I would say a quick way to do it is if you keep your players information stored in a seperate structure just move the sprites X location off the screen for 2-4 frames then restore it back to where it should be for 2-4 frames. |
Displaying alternate frames will create an interlace but NOT on every other scanline, just every other frame.. not sure why you think this would happen, if the sprite is disabled for a frame then it's disabled, the hardware doesn't draw 1/2 of it.
#939 - subbie - Sun Jan 12, 2003 5:13 pm
| Splam wrote: |
Displaying alternate frames will create an interlace but NOT on every other scanline, just every other frame.. not sure why you think this would happen, if the sprite is disabled for a frame then it's disabled, the hardware doesn't draw 1/2 of it. |
It would turn out every other scanline to the user (since we wont see the difference between frame 0 & frame 1 so it would come out looking like a sprite with lines missing). It is not 1/2 of the sprite being drawn. It is bening drawn on while the lcd only does one type of scanlines (odd or even) then off while the lcd draws the other type of scanlines. Why you need on or off for more then 1 frame if the game is running at 60hz (updating after every vblank). I did this as a cheap trick on shadows so I would not have to blend.
#942 - Splam - Sun Jan 12, 2003 5:28 pm
Admittedly what you describe would happen if you're 100% sure the lcd on gba draws alternate scanlines ? If so then surely scrolling would cause a shear and be more noticable the larger the scroll offset per frame. I can imagine there would be some artifacting (not sure how to explain what I mean) due to the display being an lcd (like ghosting) but I've not read anything specific to the gba that says it's an interlaced display. Please let me know otherwise because it could be very usefull for something else ;)
#943 - subbie - Sun Jan 12, 2003 6:07 pm
splam,
If you have hardware you can do a simple test your self to see it is interlaced. This does not show up in emulation since pc draw all scanlines but I think few emulators add scanline option. Yes you should see this a bit if you move a sprite 1 pixel a frame but most games usualy only move a sprite a pixel every few frames because if it moved 1 pixel every frame the game would move too fast.
#948 - Splam - Sun Jan 12, 2003 6:48 pm
I'll do a test app and test it but I can assure you there are plenty of games that move sprites/backgrounds at MORE than 1 pixel per frame ;)
#951 - Splam - Sun Jan 12, 2003 7:03 pm
Ok, I tested it and I don't see alternate lines being displayed, as far as i can make out it's "ghosting" (like I posted about earlier) where the lcd is just a bit too slow to alter the state on a 60hz basis (problem with most cheap lcd screens). The reason it flickers more on the emulators isn't due to interlaced lines or anything else like that. it's due to them not updating the screen in sync. The scanlines option in the emus doesn't emulate what you're talking about but rather a "draw x2 lines and make alternate lines slightly darker" for a more tv (or in this case) lcd "feel".
Also I tested with a sprite moving at 10pixels per frame and above and saw no shearing which also leads me to believe you're wrong..
Still in the end you're correct in saying that on off/on period of more than 1 frame would be better for a "flashing" sprite rather than a "flickering" one which a 1:1 ratio would give so hopefully darkcloud has what he needs now :)
#952 - darkcloud - Sun Jan 12, 2003 7:10 pm
Yea thanks you guys lol. I actually did turn my sprites on/off for more than 1 frame after trying one frame, and the flashing effect came out just as I wanted it to. Soon I'll post the game I'm making on my website (or send it in to gbadev) so you can see how it came out.
_________________
Maybe in order to understand mankind, we have to look at the word itself: "Mankind". Basically, it's made up of two separate words - "mank" and "ind". What do these words mean ? It's a mystery, and that's why so is mankind.
#953 - subbie - Sun Jan 12, 2003 7:23 pm
splam,
You might want to check that you are refreshing the data a 1/60 of a second. I just did this recently with a debug on a demo I was doing to see where I got stuck at. The screen would have the back drop color on one scanline and the normal background on the next scanline.
There is also quite a few comercial games that use this trick for shadows on floors.
--edit--
Going to do some tricks to test
#955 - Splam - Sun Jan 12, 2003 7:37 pm
Yep, running at 60hz and swapping every other frame. I've seen games that use this for shadows and it's a trick thats been used on lots of consoles too for shadows, but I still don't think it's due to interlace.
What debug environment were you using? I'm not sure I understand how you managed this as even the official debuggers don't stop the lcd updating every frame.
I'm not trying to be argumentative here, just I like people to quantify what they're saying not just to comment on something they think is correct because thats what it looks like. If someone with more actual hardware knowledge (ampz maybe, seems to know a lot of hardware/electronics) can tell me that the lcd does indeed inerlace then I'll take that as being fact :)
#962 - Touchstone - Sun Jan 12, 2003 8:42 pm
Check out this article on the subject:
http://www.pokewhat.com/touchstone/article.php?name=supertransparency
_________________
You can't beat our meat
#964 - Splam - Sun Jan 12, 2003 9:22 pm
Thanks for the link Touchstone. Now someone who has actually done intensive tests on it to prove it then I'll take it as being more likely ;)
I did another test myself to make sure, Put a screen high sprite on and set its position to one side of the screen on one frame and the other side on the other and I'm still not totally convinced it's nothing more than ghosting because then I did a 1 pixel per frame version with the same thing and I don't see the shearing on my gba.
When I get more time I'll try your transparency method (I presume it's just a case of using an hdma or h-blank interrupt to swap which lines are on/off ?).
Just wondering though with that method, how do you know which set of interlaced lines the gba is displaying?
#966 - subbie - Sun Jan 12, 2003 9:34 pm
splam,
Try scrolling a background only verticaly should show it (I notice this alot with scrolling vertical background they look streched or squashed). I did some test today and even though it more comes off as flickering it is still interlaced.
I also notice waching the gba bios intro you should notice something is very off with the text that is just not present when watched though an emulator.
#967 - Splam - Sun Jan 12, 2003 9:46 pm
There are things that make me think "yeah, interlaced" (like u say, the boot + when u turn gba off you seem to get an odd or even set of lines, but that could be caused by anything and therefore is conjecture again) but then tests I've done make me think "no, it isn't".
I've thought some more about Touchstones transparency code too, as I say, if the gba is interlacing odd/even lines, if you're out by a frame then you're going to be displaying the wrong ones and you'll see nothing. That code in itself is creating its own interlace (which means the screen MUST be 60hz update), add to that the lcd "ghosting" I keep going on about ;) you will get a pretty much semi transparent spite. on/off every other frame doesn't flicker much anyway so displaying odd/even lines instead of just straight on/off would flicker even less..
Still undecided :P
#970 - Touchstone - Sun Jan 12, 2003 10:16 pm
Splam, I can't say the gba screen is infact interlaced but in has the same characteristics. But as you asked, how can one know which field is currently being rendered, even or odd scanlines? You can't! So how come the supertransparency trick works? I can't really tell.
_________________
You can't beat our meat
#972 - Splam - Sun Jan 12, 2003 10:23 pm
Then supertransparency ( you need a TM hehe) must be because of the reasons I said above. You're actually creating the interlace yourself and because of the lcd's slow state change the odd/even lines blur (more like a scanline effect than interlace) and give you the impression of stable transparency. Without knowing which field the gba is displaying it just wouldn't work, you'd have a 50/50 chance of anything at all displaying.
#974 - Daikath - Sun Jan 12, 2003 10:30 pm
Ah well, if you can use it ingame it would be an reason for any Rom Lamers to go and buy the cartidge.
_________________
?There are no stupid questions but there are a LOT of inquisitive idiots.?
#984 - Touchstone - Sun Jan 12, 2003 11:33 pm
Actually, it's not me creating the interlace effect. If you scroll a vertical bar by one pixel each frame the edge will become jagged.
_________________
You can't beat our meat
#992 - Splam - Mon Jan 13, 2003 1:50 am
Ok, before I repeat myslef for the 10th time I had an idea. Are you using any kind of tv out (either the ones you can buy or the official devkit one)? Because I know for a fact they DO interlace the gba screen onto the tv and DO cause shearing but they're only meant for seeing things eaiser than trying to squint at your tiny gba screen.
#998 - subbie - Mon Jan 13, 2003 3:32 am
splam,
I have never used an add on tv device, IS-Capture or Wideboy 64. Only a gba sys and emulator.
#1009 - Touchstone - Mon Jan 13, 2003 11:03 am
I get your point Splam. It is impossible to know which field the screen is rendering so therefore it's impossible that the transparency effect would work if the screen was infact interlaced. Please note I've never said the screen was interlaced, I've just stated that it has similarities as in it's updating even/odd lines interchangeably. (at least it seems to me like this is what it does)
_________________
You can't beat our meat
#1016 - Splam - Mon Jan 13, 2003 1:12 pm
Fair enough and point taken :)
I just want to get to the bottom of what it's actually doing because a) I just want to know for sure now and b) it could come in handy for something and I can't be bothered at the moment rewriting lots of code to test it in something I'm working on. ;)
btw, do you do the transparency effect with hblank interrupts or hdma ? You say it's quite processor intensive and doing hblanks is quite nasty (i was doing that in Splam until recently for changing c64 colour regeisters for each line) but I've changed it to hdma and done some other stuff (along the same lines) and as long as you make sure you're sprites follow each other in OAM (reserve a few) then the hdma method is very fast BUT means wasting ram to have the repeated oam entries for each line of the sprite.
#1017 - Touchstone - Mon Jan 13, 2003 1:36 pm
I do it with hblank interrupts. Doing it with hdma sounds, like you say, faster but wastefull with the memory. Plus I'm not sure you could do this with hdma since you'd want two different sources, one for each scanline. For even scanlines you'd want sprites on screen and for odd you'd want sprites that are off screen. You could set up an hblank interrupt every other scanline to reset the source ofcourse. :)
Anyways, if you get definite and reliable info on how the screen works I'd really like to know. It would be nice to finally get an answer after 18 months. :)
_________________
You can't beat our meat
#1022 - Splam - Mon Jan 13, 2003 4:22 pm
Yeah, to do it with hdma ram usage would be corresponding to the height of the sprites (and how many).
You would need a copy of the oam for each sprite repeated by the height (which means updating all of those all the time) and alternate entries would have the sprite on then off. To get the interlace you would trigger the dma from an hblank on one line then on the next for the next frame.
The updating of the table should be quite fast because you probably only want to change the xpos (so you could turn the sprite "off" by moving it off screen with the same entry). So 1 16bit write per line + 1 hblank + a very fast hdma OR 1 write per sprite + nasty slow hblank but only on alternate lines.. There's probably not toooo much in it but the dma method would be faster. Comes down to a question of ram usage then. At least one could be used with low ram and the other if there's plenty free. :)
I've got a friend of mine who does electronics and coding to see if he can work out what the lcd is doing (without killing his gba hehe else I'll have to buy him a new one or something). Hopefully he can sort it out :)
#1031 - ZoneGN - Mon Jan 13, 2003 8:20 pm
hi all,
About the "supertransparency".
I have tested it some month ago and I use it some time.
Im not sure but it's probably a special trick made by Nintendo.
it's work only on hardware and I don't know if it work on the Gameboy player for gamecube. (maybe yes, because somes good games use this trick like the blue shadow on Castlavania : Harmony of Dissonance)
I also tested with the TV de advance device and the result is very very bad !
You can create other trick like other transparence level:
( it's work only in 60fps)
Opacity 75%=Show sprite(2 frame), Hide sprite(1 frame)
Opacity 50%=Show sprite(1 frame), Hide sprite(1 frame)
Opacity 25%=Show sprite(1 frame), Hide sprite(2 frame)
( you can also combinate this with a blend sprite for more level precision )
I test it, and it work well.
however, your can test the 50% opacity on visualboy advance with the filter "Motion blur". Of course, look only your trick/sprite not the background. Use this only to make a fast preview of your trick/sprite ( not for play the game ! )
You can also use the trick for the background. ( active/desactive the needed Background)
Another good things when you work with 50% opacity/trick is that you can simulate 2x more sprite at the screen by switching a sprite with another sprite.
for example, image you use 2 sprites on 50% opacity/trick, switch simply these 2 sprites with the same OAM.
Yes, really good for make at the same time 2x more shadow sprite on the screen.
But use this trick only for make "detail" because, if you look carefully the gba screen with this effect, you not see a perfect transparence, trust me...
#1844 - FluBBa - Fri Jan 24, 2003 10:16 am
Well the GBA (and GBC) displays are interlaced, but not as one would think of it normaly.
If you put up a flashing (on/off 60Hz) white square on a completly black background. You will get "lines" in the square but they are not just white and black, you will get something like white and grey.
If I recall this right it had to do with that the display "pushes" everyother line towards light (white) and everyother line towards dark (black), and then alternates, this. If they had done the same thing on every line and instead alternated everyother frame you would have got a strobing screen.
As someone said before this can be seen when you turn off your GBA or when entering sleep mode in a game (try pocketnes). This way you can see that the display allways wants to go completly white. I think this is why you would get grey instead of completly black on the lines that try to alter the colours towards dark. If you instead use a grey square it's not that obvious anymore.
/FluBBa
#1997 - chrisbtoo - Mon Jan 27, 2003 2:25 pm
| Splam wrote: |
| Yep, running at 60hz and swapping every other frame. |
Do you mean "every other frame" or do you mean "every frame"? If you mean what you say, then you're switching at 30Hz intervals, not 60Hz, and you won't see any shearing because every time you move the screen, both interlaced lines will have been drawn.
#1999 - chrisbtoo - Mon Jan 27, 2003 2:53 pm
Duh, I didn't see the rest of the thread, where Splam goes on to describe what else he did. Ignore me :-)