Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (108)
games submitted by our members
Games in WIP (536)
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  
  What "technique" is Notch using?  (Read 3276 times)
0 Members and 1 Guest are viewing this topic.
Offline jhallenberg

Senior Newbie





« Posted 2012-09-27 11:08:07 »

When I was watching Notch develop a game for a competition, I noticed that his textures/sprites are all gray on file, but in-game they are coloured? I've been trying to figure out what that technique is called. Could someone tell me if they know?

Thanks.
Offline Phased
« Reply #1 - Posted 2012-09-27 11:13:34 »

In Minecraft, they are coloured, except for particles, I don't think theirs any name for it, his just colourizing the images.

in LWJGL, you can set the colour of an image before rendering it, then it will change the colour of it.

His basically just setting a different colour to the different colours on the sprites.

e.g. most of his games that are not Minecraft, the sprite sheet is pink. all colours that are pink are then set to fully transparent.

When he sets the image, he would cycle through the pixels of the image, changing all the pixels that are coloured a certain colour to another colour.

EDIT: added some stuff
Offline jhallenberg

Senior Newbie





« Reply #2 - Posted 2012-09-27 11:15:35 »

Okay. The game he was developing when I was watching was "MiniCraft" I believe.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Phased
« Reply #3 - Posted 2012-09-27 11:16:29 »

Yeah, read the last 2 lines before the edit, I added what I think he did for that.
Offline jhallenberg

Senior Newbie





« Reply #4 - Posted 2012-09-27 11:20:42 »

I think that sounds pretty interesting. Is it performance efficient or just to skip colouring the textures?
Offline Phased
« Reply #5 - Posted 2012-09-27 11:23:58 »

Im not to sure on performance, if their is, its going to be like 1ms difference lol.

He uses the character drawing as the zombies too just recoloured, this would save him having to copy recolour the image, (if I remember right, the characters are made of 2 or 3 colours)  so he only has to copy and paste the code, and change the colour the pixel is point 2.
Offline jhallenberg

Senior Newbie





« Reply #6 - Posted 2012-09-27 11:25:30 »

Yeah that makes sense, I guess it's nothing to go for if you're not going to be using a lot of the same textures.
Offline Phased
« Reply #7 - Posted 2012-09-27 11:29:17 »

yeah, maybe someone else may have a different input on reasoning why it may be better.
Offline DrHalfway
« Reply #8 - Posted 2012-09-27 15:32:43 »

It is for flexibility purposes - so you don't have to create the same sprite multiple times, you just reuse the same sprite texture and re-color it to however many colors you like. I personally use a custom "Color" that accepts integers for r,g,b,a values of  0,0,0,0 to 255,255,255,100 respectively. We simply load up a "white" sprite and color it to whatever we wish at runtime.

Some other awesome things you can do is create a "color" interpolator, where you can linearly interpolate from one color to another at runtime for awesome effects, very handy for complex particle systems.

For reference purposes, as far as the GPU is concerned, it is an extremely fast operation, using glDrawElements and a glColorPointer I notice a 2FPS difference on a 15,000 sprite test (66FPS colors off) vs (64FPS colors on). That 2FPS could also be the fact that an extra buffer needs to be created for each sprite, so it could very well be a CPU bottleneck in which case no difference in render speed.

PS - here are some images - is this what you're describing? thats 15,000 sprites, one version colors turned off, the other colors turned on. 69 FPS colors off, 68 FPS colors on. Colors chosen randomly.




Offline davedes
« Reply #9 - Posted 2012-09-27 17:37:27 »

DrHalfway -- did you optimize for grayscale by specifying less vertex attributes to the shader? Enabling and passing 4 versus 8 attributes per vertex might make for a more significant difference.

1  
{x, y, u, v} vs {x, y, u, v, r, g, b, a}

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

JGO Kernel


Medals: 202



« Reply #10 - Posted 2012-09-27 17:47:25 »

It took me a while to grok Minicraft's color system while doing my scala port -- Notch isn't big on comments.  It's kind of clever and nice for dynamically colored stuff, but I'd say for most games it isn't worth it, especially not the way he packs in the whole 4-color pallette into a single int.
Offline Tjstretchalot

Junior Member


Medals: 2
Projects: 1



« Reply #11 - Posted 2012-09-27 17:56:34 »

I think the reason he does it that way is because he probably needed something like that for his earlier games and got really good at it, so he finds it easiest to use that system and it does have a few benefits. (Can make textures a little bit more random if he wanted to, etc)

Really, it's just whatever works for you imho.
Offline Rorkien
« Reply #12 - Posted 2012-09-27 19:17:49 »

As far as i can remember:

He has the sprites drawn in a 8x8 grid, colored in a 3-color grayscale
When drawing, he has a code that replaces that 3-color pattern for another one of his choice.

In shorts, you might want to use this method if you are planning on having the same sprite in several different color patterns. Otherwise, just color your sprites directly in the image.
 
@DrHalfway: Minicraft has a 160x120 screen, with 24x24 (scaled up 3 times) tiles. One layer of sprites for the world, one for the items, and one for the npcs
That's 19200 pixels for the screen and 576 for a tile. Which is 34 sprites for a layer, at most, rounded up, or 102 sprites for the whole game.

Of course handling pixel-arrays is slower than lwjgl. But seeing 15k sprites being recolored in 1 frame worth of performance, is awesome.
Offline Screem
« Reply #13 - Posted 2012-09-27 21:53:24 »

I find Notch's version of per-pixel changing rather limiting. For one thing, with the way he implemented it, you're limited to a maximum of 256 colors (I think it's actually 216, but I'm not 100% sure). On top of that, you're kinda limited to using very few different shades of colors in each sprite, otherwise you'd have to specify a dozen or so colors for each sprite, which can get annoying pretty easily (having to remember which shade of gray goes with which color, finding the color you want to change, etc). Another point is re-sizing. Everything rendered is placed inside a pixel array somehow connected** to a BufferedImage the size of the screen as it woud be in 1:1 scale. Only when the BufferedImage is rendering does it's scale multiply by three. So basically, scaling is restricted because the dimensions of the BufferedImage are in 1:1 scale, not 1:3 scale.

So yeah. I find it much better to just color the sprites in your SpriteSheet, and forget about changing colors in your code.

**Notch gets the pixels of a BufferedImage with [size=8pt]"int[] pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();"[/size] and any changes he makes to the array automatically get reflected in the BufferedImage. If someone could explain why this is, that would be great as I've been wondering for a while.

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #14 - Posted 2012-09-27 22:10:53 »

**Notch gets the pixels of a BufferedImage with [size=8pt]"int[] pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();"[/size] and any changes he makes to the array automatically get reflected in the BufferedImage. If someone could explain why this is, that would be great as I've been wondering for a while.

If this really is the case... Then intresting Cheesy
And then it's like this:

Do you know what a pointer is? A pointer is (actually) an int/long, which "points" to a position in memory. Usually you use them to "find" Object instances. for example:
1  
MyReference ref = new MyReference("This is the known constructor");

in which case the constructor would "return" a pointer to newly allocated memory.

In java almost everything is a pointer. So actually everything exept byte, short, char, int, long, boolean, float, double.
So int[] is actually a pointer to a specific point in memory. And the int[] you get returned is a pointer pointing directly at the buffer array used by the BufferedImage, which also means, that this is JUST the array used to render the pixels for the BufferedImage.

And actually this is only a guess Grin But It seems to be like that.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Screem
« Reply #15 - Posted 2012-09-27 23:09:52 »

Hmm... interesting. I wonder why [size=8pt]getRGB()[/size][/b] doesn't do that, then. Would save you having to use [size=8pt]setRGB()[/size][/b] afterwards. Anyways, back on topic I guess, sorry for hijacking this thread. Cheesy

Offline DrHalfway
« Reply #16 - Posted 2012-09-28 01:19:28 »

DrHalfway -- did you optimize for grayscale by specifying less vertex attributes to the shader? Enabling and passing 4 versus 8 attributes per vertex might make for a more significant difference.

1  
{x, y, u, v} vs {x, y, u, v, r, g, b, a}


Depending on engine setup we use either packed color or raw, there is about 3FPS difference between the two. Packed color basically packs the rgba component into a single 32 bit float and passes directly, non packed uses 4 32 bit floats for rgba.

So packed looks like this, where c is the color as a 32 bit float

1  
{x, y, c, u, v}


And unpacked

1  
{x, y, r, g, b, a, u, v}


The above example is a bit slow, those 15k sprites are 15k Dynamic GameObjects moving around, so a full transformation matrix is computed for each one and transformed before rendering. We use specialized rendering for particles and static (non moving) GameObjects which skips alot of the expensive transformations for faster rendering. Same technique though.

Offline SwampChicken
« Reply #17 - Posted 2012-09-28 04:43:05 »

jhallenberg,
Watch video #2 onwards from this thread here.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (17 views)
2014-07-30 21:08:39

Riven (23 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43
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!