How does puppygames do it?

Puppygames always have these sexy vibrant neon colors. They look nothing like something in a sprite. Are they mapped on dynamically. Is it some sort of cool lighting trick? I just want to know because its pretty eye-gasmic. :stuck_out_tongue:

Rayvolution: Yup, just a little bit more hopping around. Want to join my game of hopscotch? I’m a curious guy, I have many questions.

If you read princec’s ā€œAsk me anythingā€ thread, you’ll learn a lot, guaranteed. More insights can be found on the puppygames devblog.

Short answer to your question: it’s all sprites, just separated into base, shadow, and glowy stuff layers, IIRC.

Thanks for the referral! :point: ;D

lol. :wink:

Actually asking random how-to questions like this are fine (and so was your other one really) I was just saying you should spend more time developing your game and less time on over thinking the what if scenarios, else you’ll never get any one thing done. :stuck_out_tongue:

Don’t mention it, but next time try a little search or problem solving first. ā€œHow does this game work?ā€ --> ā€œI know the dev is here on the forumsā€¦ā€ --> ā€œHe might have talked about, I’ll check his profile.ā€

Also relevant, he released the RoTT source here: http://www.java-gaming.org/topics/revenge-of-the-titans-source-code/24119/msg/202029/view.html
You may or may not gain all powerful knowledge by browsing through it.

I still would get nothing done. :stuck_out_tongue: I seem to be a chronic procrastinator. ;D I try my best. My problem is my flow of ideas. One day I’m dead set on making a space shooter. The next day I’m swayed to make a survival simulator. And then when I do try to make a complete game, I rush it because I want to get started with ā€œthat next big ideaā€.

Perhaps try keeping a ā€œgame bookā€ where you write down the ideas, as completely as possible, when you get them, that way even if you move on to something else you can easily come back to it or say, ā€œhey, I remember that, that would be cool, let’s do it.ā€

I should follow my own advice… :clue:

I should follow advice in general. I tend to be stubborn sometimes. :stuck_out_tongue:

It’s not anywhere near as complicated as it looks… we are the masters of cheapass effects.

The neon look… well, that’s just additive blending. Know this about blending:

  1. When you load a .png you must premultiply the RGB values by the alpha value. I was using coerceAlpha() to do this but was having some strange issues with it, I’ll revisit that…
  2. When you’re using premultiplied alpha textures, you use the blending mode GL_ONE, GL_ONE_MINUS_SRC_ALPHA for both transparent and additive sprites.
  3. More recently discovered by theagentd, if you’re doing actual glows, a mode of GL_ONE_MINUS_DST_COLOR, GL_ONE_MINUS_SRC_ALPHA might look better. We’re experimenting with that in a new game to see if it’s better or not. I’d prefer not to use it because it means a state change at awkward moments. Only significant if you’ve got tens of thousands of sprites to draw though.

The other trick up our sleeve is Chaz, who has some sort of enlightened sense of colour. I think he may be a tetrachromat. Chaz tends to define colours using HSB rather than RGB as well, which can make it a lot easier to pick colours that look good together by twiddling values.

Chaz takes extreme pains to make animations and particle emitters. The emitters are surprisingly complex. Not only are the particles themselves often actually animated sprites, they animate in size, colour, and alpha over time too, and often have slave emitters attached to the particles (which in turn emit more particles). He can spend a whole day on a single emitter.

One more tip… keep your frame rate at a rock solid 60Hz and almost anything looks professional. Vary your framerate and it’ll look amateur. Werd.

Cas :slight_smile:

lol, that made me chuckle, because it reminded me of how I feel about my pseudo/fake-dynamic shadows engine. Just very carefully put together simple effects. ;D

The guys who are ā€œohh and ahhingā€ my shadow code would laugh if they ever saw it, it’s only 72 lines of code. If you remove blank lines and debug code it’s probably only 60~ >_>

Although it might gain a whole 10-15 more lines soon, I need to tweak it so the shadows detect the time of day and level the alpha levels at nighttime, because the shadows shouldn’t really be (as) visible anymore.

All the more reasons to stray away from Slick2D I suppose. LWJGL scares me though. Is is gunna eat me?

Just keep your buffers well fed and you’ll be fine.

Rather than starting from scratch with LWJGL you should probably use libgdx.

Cas :slight_smile:

You can completely bypass Slick2d and use all the features of LWJGL directly if you want. :smiley:

I’ve done that in quite a few places in my game, for example, the latest version of Slick2D doesn’t really support resizable windows (gc.setResizable was removed for some reason) so I control all of that directly through LWJGL. Same with the GL shaders Cas was talking about, my entire lighting engine pretty much doesn’t use Slick, aside from uses newdawn.slick.Image to load the light images.

Not really trying to defend Slick or anything, LibGDX is a wonderful (and more updated) library, I just personally prefer Slick. Just saying, if you want to fiddle around with LWJGL directly you don’t have to drop Slick2D to do it. :stuck_out_tongue:

You can also use straight LWJGL code in a libGDX app, nothing stopping you there either, but there’s not many reasons to do so most of the time.

If you’ve seen the game I made, It took about 4 days of learning LWJGL. It is a wrapper for OpenGL, so it contains the same methods.(Except it’s Java :P)