Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Thanks Kevin, look what you did ;)  (Read 4563 times)
0 Members and 1 Guest are viewing this topic.
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Posted 2003-07-21 08:51:12 »

Kevin Glass recently posted on some "glowing" effects in 2d. That got me thinking..... My RPG will need some transition effects. Is there an easy way to impliment thing like fade from one screen to another?

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #1 - Posted 2003-07-22 16:24:44 »

Isn't there anyone who knows how wI can achieve some sort of transition effects ?

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline kevglass

« JGO Spiffy Duke »


Medals: 319
Projects: 25
Exp: 22 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2003-07-22 16:27:48 »

I'm not quite sure how you'd achieve full screen effects like fade at any decent speed. You'd probably have to do an AlphaComposite across the whole viewable screen.

This might be ok speed wise, take the current screen, combine it with an AlphaCompositeOp onto the destination screen. It might work, but I have a feeling it could be quite slow..

You might want to try and think of other transitions that would look good.. I always wanted to try and implement the cartoon "black circle surround" zoom in at the end of warner bros toons.. Smiley

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #3 - Posted 2003-07-23 01:27:32 »

Its very fast if you are using acclerated images with alpha transparency accelerated.

Just create a black image the size of your screen. Start the image at full alpha (painted over the top of your current drawing surface), fade to no alpha(at desired speed). Strop drawing old image and start drawing new background. Fade back to full alpha and discard black image until you need it again. takes no time to create this image and with 1024x768 will take 4mb of ram so I just destroy it and recreate it when needed.
Offline kevglass

« JGO Spiffy Duke »


Medals: 319
Projects: 25
Exp: 22 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2003-07-23 06:39:22 »

Whats it like with unaccelerated Alpha?

Kev

Offline krypto

Junior Devvie




while(true) { self.caffeinate (); }


« Reply #5 - Posted 2003-07-24 09:05:09 »

Quote
Its very fast if you are using acclerated images with alpha transparency accelerated.


I did as you said and it seemed pretty slow, perhaps usable but still slow.
I did some profilling and its taking about 250 ms per drawImage after I set the Composite. Creating the composites takes no time at all.

I am using a VolatileImage for the baackground and forground, and I have all the appropriate flags set.  Huh

JRPG Users -  General Users Site
JRPG Developers -  The JRPG Project's Home
Offline beowulf

Senior Newbie




got root?


« Reply #6 - Posted 2003-07-25 14:02:08 »

Just an idea from a long-time-lurker...  Would it work to create a number of pallets, each with the colors shifted closer to black, and switch between pallets at a predetermined rate.  If you do it quick enough (3 second fade) then you probably wouldn't even need that many unique pallets since no one would really notice the details of the change.

-Lawrence
Offline kevglass

« JGO Spiffy Duke »


Medals: 319
Projects: 25
Exp: 22 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2003-07-25 14:07:22 »

Coo, Old Skool! Smiley

Unfortunatly, I suspect that the images/screen that are being used are palette based, but rather RGB(A). So it wouldn't work unless you converted all your images to TYPE_INDEXED.

Kev

Offline beowulf

Senior Newbie




got root?


« Reply #8 - Posted 2003-07-25 15:13:12 »

Did I date myself that bad?  I'm just starting to get into hobby game programming w/ Java and am still reading here and on other sites.  Lots to learn still...

-L
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #9 - Posted 2003-07-25 16:55:52 »

Quote
Did I date myself that bad?  I'm just starting to get into hobby game programming w/ Java and am still reading here and on other sites.  Lots to learn still...


Pallette swapping hasn't been a tremendously viable choice since about 1996, when SimCity was still telling you to change windows to 256 color mode. Pallette swapping allows for some pretty cool effects, but programmers hated the pallette because of how difficult it made their lives trying to cram all the colors in the world in less than 256 choices. Not to mention that some of those would get used up for special effects.

Of course, if you *really* wanted to date yourself, you should start talking about Sprite *hardware* that generated the NTSC signal from a combination of background and sprite characters. Or the fun little handheld game of football that was nothing more than a 6x3 array of calculator lights, or the Sega Master System, or the original game of pong...

Java Game Console Project
Last Journal Entry: 12/17/04
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #10 - Posted 2003-07-25 19:59:31 »

Quote
Of course, if you *really* wanted to date yourself, you should start talking about Sprite *hardware* that generated the NTSC signal from a combination of background and sprite characters.


That's not much different than what we have today.. We just have millions of triangular sprites now Smiley and send the image to an intermediate frame buffer before generating the video signal.

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #11 - Posted 2003-07-26 02:28:00 »

Erm, no. I don't think you quite understand how it works. There were *two* frame-buffers (sort of). One for sprites and one for the background. The hardware would then generate the signal from these two separate sources. Sprites were actually just cut out chunks of vid-mem with locational data for the hardware to work with. Thus, you never really had to blit ANYTHING. You just told the hardware, "This chunk of memory is here on the screen, this chunk is here, and that chunk is there. And while you're at it, I've got this lovely backdrop for the whole thing." There's no way in God's creation you were going to blit anything with a 1Mhz processor running your game. Smiley Even if it had been possible, there wouldn't have been enough CPU left to simply calculate collisions and movements for games like 1942 where the bad guys generally tried to swamp you.  

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Orangy Tang

JGO Kernel


Medals: 57
Projects: 11


Monkey for a head


« Reply #12 - Posted 2003-07-26 10:37:15 »

Quote

Of course, if you *really* wanted to date yourself, you should start talking about Sprite *hardware* that generated the NTSC signal from a combination of background and sprite characters.


So.. much like the GBA then? Not exactly what i'd call outdated hardware Tongue Modes 0, 1 and 2 give you up to 4 tile layers with varying amounts of control for positioning and scaling/rotation. The other three modes give you a big hunk o memory for the bg, much like the old mode 13h in DOS, but you get to have 128 hardware sprites regardless of the mode you're working in Smiley

Back to the original question - how about freezing your image, then chopping it up into tiles - if you use Volatile images you should be able to do it all in vRam and keep the speed up. Then you can do one of those nifty shatter effects where  the screen dissolves into fragments and whirls off screen. Skys of Archadia has a million different variations on this that look great if you want some ideas (whirlpools, fountains, shatters, zooms..)

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline beowulf

Senior Newbie




got root?


« Reply #13 - Posted 2003-07-26 12:18:50 »

Thanks, JBanes.  Most of my experience (very limited) with game programing so far has been work out of the "Teach yourself...21 days" and "Black Art of" books...and those were from the Win32 days.  I'm only recently starting to get into Java game programming as a hobby and have a lot of key concepts to un-learn and re-learn.

You know, the current state of Java game programming really feels like the Win32 environment years ago.  Many people then said you will never get the performance needed to run a game under Windoze (remember rebooting in DOS mode everytime you wanted to play Wing Commander?), just as there are naysayers today with Java. In time some creative people proved them wrong and now Win-based games are the mainstream.  It's really exciting to see people on some of these message boards that are breaking down those same barriers again.  

-Lawrence
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #14 - Posted 2003-07-27 01:33:30 »

Quote
Erm, no. I don't think you quite understand how it works.  


Trust me I understand sprites perfectly and could probably design a graphics controller that implemented them in VHDL if I had the time.

I meant that the process of current video cards rendering textured polygons to frame buffer is similar to the old way of drawing the background and sprites on each scanline of video signal output.  Just based on the fact that they deal with the z-ordering and fetch the image data from different areas of video memory.  Polygons are 'scan converted' in a process that renders them to the frame buffer in a way similar to the way background and sprites were rendered on the fly as the video beam of the CRT was scanned over the monitors phosphors.  The details are of course very different, but the effect is similar..  you could if you wanted, consider each triangle of a 3D card to be a kind of advanced sprite since they can be moved independent of each other and static background graphics without your program manually having to redraw the exposed areas or clip based on depth, etc..  When you rotate them in 3 dimensions and stretch and warp them you can see how they are most definitely not like sprites though.

The only thing left that is truly sprite-like today is the hardware cursor of the video card.  Imagine have 8 or 256 of those and a background bitmap and that is what you were dealing with for some of the old graphics hardware.  

The Commodore Amiga was the one of the truly revolutionary designs in the old days.  With the first commercial blitting hardware, sprites, and a dual-playfield mode, and a programmable co-processor specifically for video effects.  The CPU was a 3.58MHz Motorola 68000.. That clock frequency chosen to match the color subcarrier of a composite video signal.
With the dual playfield mode you could have two framebuffer video layers that could be organized as foreground/background, or two backgrounds with parallax, with the sprites placed behind, between or in front of those layers.. All of the layering was done as the video signal was generated, and there were hardware registers to adjust the memory pointer for where the bitmap began in video memory.. simply adjusting those registers had the effect of smoothly scrolling the playfield.
I won't mention that wacky Hold-And-Modify mode they used to get 12 bit RGB color from a 6-bit memory buffer.. some very creative workarounds for the technological limitations of the day.

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #15 - Posted 2003-07-28 12:32:16 »

The effect is similar, but it really isn't the same thing when it comes down to it. 3D cards simply accelerate 3D -> 2D transforms and blitting the result into a frame buffer. Back in the day, you just didn't *use* a framebuffer for games. It was rediculous. Hardware was so much faster than software! Framebuffers were for business apps where you needed pretty controls like buttons or abitrary graphics visualization. (Anyone remember when JPEGs were a huge thing to the space community? "I can get hi-res shots of the moon in only 30K"!!!) But yes, the end effect is the same. That's much of the reason why 3D cards have supplanted specialized 2D hardware. I was just making the point that programming the old hardware was very different.  Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (148 views)
2017-09-30 02:57:34

theagentd (213 views)
2017-09-26 18:23:31

cybrmynd (296 views)
2017-08-02 12:28:51

cybrmynd (285 views)
2017-08-02 12:19:43

cybrmynd (295 views)
2017-08-02 12:18:09

Sralse (288 views)
2017-07-25 17:13:48

Archive (967 views)
2017-04-27 17:45:51

buddyBro (1093 views)
2017-04-05 03:38:00

CopyableCougar4 (1665 views)
2017-03-24 15:39:42

theagentd (1426 views)
2017-03-24 15:32:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!