Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
OneEightHundred
Feb 28, 2008

Soon, we will be unstoppable!

Pfhreak posted:

Now I tend to start with small goals in mind -- get the player moving, get the camera panning, add an inventory, how about bad guys, etc. I tackle that one problem in code with little planning.
Other thing I'd add is to freeze your feature list early, a big part of not overengineering is knowing what you do and don't need to add support for. This has benefits in the gameplay too.

Adbot
ADBOT LOVES YOU

Zhentar
Sep 28, 2003

Brilliant Master Genius
I'd also recommend prioritizing said feature list as well. I find that once I've already put something down as lower priority, it becomes a lot easier to decide I don't really need that feature when I'm behind schedule.

SuicideSnowman
Jul 26, 2003
Anybody here ever played around with the C4 3d engine?

http://www.terathon.com/c4engine/index.php

I like Unity but I feel with each new release they keep making the free version less and less appealing and the $1500 is not a price I'm really wanting to pay right now.

UDK has some great features but I don't really care for the whole scripting aspect of it. I know it's possible to make a variety of games with it but the way it's put together makes it feel as if I'm still just making a complicated mod. Not to mention I'd like to play around with implementing some 3rd party libraries and that's not really possible with UDK.

The C4 engine is $250 and it has some pretty impressive features, including a nice voxel terrain system. Not to mention the full source is included. Just curious to know if anybody has had any experience with it.

HaB
Jan 5, 2001

What are the odds?
I don't see a Minecraft-related development thread, so I figure I'll ask here just in case.

Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location"

And that's all well and good except it's not random. If I start a world with a particular seed, open it up, check my spawn coords, then delete the world and re-create using the same seed, I get the same spawn point.

So...does anyone know what method it's using to choose? Thanks in advance.

Zhentar
Sep 28, 2003

Brilliant Master Genius
In this context, "seed" is short for "random seed". The whole point of entering the seed is that exactly the same "random" numbers will come up when you use it.

HaB
Jan 5, 2001

What are the odds?

Zhentar posted:

In this context, "seed" is short for "random seed". The whole point of entering the seed is that exactly the same "random" numbers will come up when you use it.

Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is.

ShoulderDaemon
Oct 9, 2003
support goon fund
Taco Defender

HaB posted:

Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is.

It is as you described. Minecraft picks a random point within a few hundred blocks of (0,0) until it finds one that's an acceptable spawn location.

Scaevolus
Apr 16, 2007

HaB posted:

So...does anyone know what method it's using to choose? Thanks in advance.
It generates random points near the origin until it finds one that's sand on top.

HaB
Jan 5, 2001

What are the odds?

ShoulderDaemon posted:

It is as you described. Minecraft picks a random point within a few hundred blocks of (0,0) until it finds one that's an acceptable spawn location.

If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it:

Load Minecraft.
Create a New World, Select More World Options
Enter 1 as the seed
Create World
when it loads, don't move and hit f3 to look at your coordinates.
You are standing at: (251.5, 65.6, 232.5)

If it's random, then how do I know where YOU are standing?

It's based on the world seed. I'm trying to figure out HOW.

Gough Suppressant
Nov 14, 2008
There is a minecraft modding thread in Games which would probably be more able to answer your question.

Orzo
Sep 3, 2004

IT! IT is confusing! Say your goddamn pronouns!

HaB posted:

If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it:
I'm not sure I follow. The algorithm which generates worlds is using a random number generator with a seed. The algorithm which places the player is using the same seed. So it appears 'random', although it is deterministic when you give it a certain seed. As for what the algorithm is, you'd need the source code.

ShoulderDaemon
Oct 9, 2003
support goon fund
Taco Defender

HaB posted:

If it's random, then it wouldn't be the same every time the same seed is used.

Sure it would be. That's what random seeds are. If you use the same seed, you'll always get the same sequence of pseudorandom numbers.

The seed you give to minecraft doesn't go into some fancy "world gen seed algorithm". It's just used to seed the standard random number generator, which is then used to build the world. Immediately after building the world, that same random number generator is used to pick the spawn point.

There's nothing clever or unexpected going on. If you give a fixed seed to a random number generator, it will always produce the same sequence of numbers. Minecraft uses some of those numbers to generate the world, then it uses some of them to pick a spawn point. Because you provided a seed, you get repeatable results.

HaB
Jan 5, 2001

What are the odds?

Orzo posted:

I'm not sure I follow. The algorithm which generates worlds is using a random number generator with a seed. The algorithm which places the player is using the same seed. So it appears 'random', although it is deterministic when you give it a certain seed. As for what the algorithm is, you'd need the source code.

Jeez, guys. I know how pseudorandom number generators work! The same as they have worked since time immemorial. I bolded the ACTUAL answer above. But I know other people have already decompiled and deobfuscated the code, so I was just asking if anyone knew the algorithm offhand or could at least point me in a direction other than "this is how random number generators work." :downs:

MonsterUnderYourBed posted:

There is a minecraft modding thread in Games which would probably be more able to answer your question.

Ah-ha! I only looked in Cavern of COBOL. Thanks.

Zhentar
Sep 28, 2003

Brilliant Master Genius

HaB posted:

Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is.

The "equation" is a psuedo random number generation algorithm. To determine the output of a specific call, you need to know not only the algorithm, but the position in the sequence. If the worldgen process always performs exactly the same number of random calls before that point, then you'd just need to figure that, say, the 127,403rd time random() gets called it's to pick the spawn point. However, I would assume that the worldgen process also involves testing and rejecting candidates, in which case the position would be variable. You'd likely have to perform most of the worldgen process to determine what the random value used to pick the spawn point is.

Pretty Cool Name
Jan 8, 2010

wat

e: derp.. Heh, random!

poemdexter
Feb 18, 2005

Hooray Indie Games!

College Slice

Zhentar posted:

The "equation" is a psuedo random number generation algorithm. To determine the output of a specific call, you need to know not only the algorithm, but the position in the sequence. If the worldgen process always performs exactly the same number of random calls before that point, then you'd just need to figure that, say, the 127,403rd time random() gets called it's to pick the spawn point. However, I would assume that the worldgen process also involves testing and rejecting candidates, in which case the position would be variable. You'd likely have to perform most of the worldgen process to determine what the random value used to pick the spawn point is.

But if the world gen tests and rejects the same seed, it would have exactly the same amount of tests and rejects everytime! The point of the "seed" is so that you can have deterministic randomness.

Serenade
Nov 5, 2011

"I should really learn to fucking read"
I've heard several times that the best way to get better at a craft is to practice it every day. I was wondering how one could apply this to game design.

The answer of 'make a game every day' seems like an unreasonable starting point. Simply writing down game mechanics in a notebook doesn't seem the same taking an idea and putting it into practice.

I suppose simply changing it from 'per day' to 'per week' could work.

Gough Suppressant
Nov 14, 2008
Iteration is a very important part of most game design processes.

Nippashish
Nov 2, 2005

Let me see you dance!

Serenade posted:

I've heard several times that the best way to get better at a craft is to practice it every day. I was wondering how one could apply this to game design.

The answer of 'make a game every day' seems like an unreasonable starting point. Simply writing down game mechanics in a notebook doesn't seem the same taking an idea and putting it into practice.

How about working on a game every day? Sounds pretty simple to me.

Do you think authors write a new book every day? How about an architect designing a new building every day? A composer writing a new symphony every day? A developer (of any sort) building a new application every day?

What I'm trying to say is you should think about what that adage means before you try to put it into practice. There are very few things in life worth doing that can be done in a day.

Jewel
May 2, 2009

Nippashish posted:

How about working on a game every day? Sounds pretty simple to me.

Do you think authors write a new book every day? How about an architect designing a new building every day? A composer writing a new symphony every day? A developer (of any sort) building a new application every day?

What I'm trying to say is you should think about what that adage means before you try to put it into practice. There are very few things in life worth doing that can be done in a day.

A lot of musicians do write songs every day as practice actually!

Pfhreak
Jan 30, 2004

Frog Blast The Vent Core!

HaB posted:

If it's random, then it wouldn't be the same every time the same seed is used. That's what I'm saying. Here's a test to prove it:

Load Minecraft.
Create a New World, Select More World Options
Enter 1 as the seed
Create World
when it loads, don't move and hit f3 to look at your coordinates.
You are standing at: (251.5, 65.6, 232.5)

If it's random, then how do I know where YOU are standing?

It's based on the world seed. I'm trying to figure out HOW.

Because once you have a seed, it's no longer random. A random generator is deterministic for any given seed. For example, seed 332 might produce HHTHHTHT for random coin tosses. It will ALWAYS provide that output. So games will generate a random seed using something that isn't known in advance -- the current time for instance.

In minecraft's case, when you enter 1 as a seed, you determine ALL the outputs of the random number generator for the rest of the game. The first coin toss it makes in generating the world will ALWAYS be a heads. So once you know the seed, you know exactly how world generation will go.

Smug guy posted:

Jeez, guys. I know how pseudorandom number generators work!

Clearly this is not the case.

PalmTreeFun
Apr 25, 2010

*toot*

Vinterstum posted:

1. Figure out the simplest thing you can possibly put on screen, as your first step.
2. Code it the simplest and most straightforward way you can imagine. Plan nothing ahead.
3. Figure out what the next logical step is, which gives you a sense of visual progress (i.e. your game is getting somewhere, not your code).
4. Refactor existing code if needed (do not skip this), and then implement that step the simplest way you can.
5. Goto 3.

Done.

This is pretty much exactly how I code, but in addition to step 1 and 2 I like to write out the basic idea of what I'm going to do with just comments. Make a short list of goals to complete step 2, and then once you get in the groove it's easy to keep going.

westborn
Feb 25, 2010

Pfhreak posted:

Clearly this is not the case.
:psyduck:
Could you people get of your high horses for a second and actually read his initial question. He clearly does know how the seed for the terrain generation works. He was asking how the spawnpoint is determined afterwards, as Minecraft has/had the tendency to not always spawn you at the same point on the same seed.
That's why the web is telling him it's a "pick some random locations near 0,0,0 till you find sand" approach, but his observation is that it's not.
So he thinks it's probably connected to the seed and therefor not random at all.

Somehow some of you only read every second word and post to form "Hey guys, wtf, this seed generates the same terrain every time, how does it do that?"
The post you quoted was him showing the spawn isn't random, not him trying to show the world generation with the same seed isn't random and trying to figure out why...

ZombieApostate
Mar 13, 2011
Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

:allears:
It's probably just doing something along the lines of x = randomNumber(), y = randomNumber(), z = randomNumber(), in which case, all you need to know is how random numbers are generated. It might be incrementing the coords by the random numbers or something so you don't repeat or run through all the spaces in whatever limit you supply your random number generator, but that isn't really much of an algorithm, which is, I think, why everybody is giving similar answers about how random numbers are generated.

HaB
Jan 5, 2001

What are the odds?

westborn posted:

:psyduck:
Could you people get of your high horses for a second and actually read his initial question. He clearly does know how the seed for the terrain generation works. He was asking how the spawnpoint is determined afterwards, as Minecraft has/had the tendency to not always spawn you at the same point on the same seed.
That's why the web is telling him it's a "pick some random locations near 0,0,0 till you find sand" approach, but his observation is that it's not.
So he thinks it's probably connected to the seed and therefor not random at all.

Somehow some of you only read every second word and post to form "Hey guys, wtf, this seed generates the same terrain every time, how does it do that?"
The post you quoted was him showing the spawn isn't random, not him trying to show the world generation with the same seed isn't random and trying to figure out why...

Bless you, sir. :)

ZombieApostate posted:

It's probably just doing something along the lines of x = randomNumber(), y = randomNumber(), z = randomNumber(), in which case, all you need to know is how random numbers are generated. It might be incrementing the coords by the random numbers or something so you don't repeat or run through all the spaces in whatever limit you supply your random number generator, but that isn't really much of an algorithm, which is, I think, why everybody is giving similar answers about how random numbers are generated.

I spent a few hours last night wading through the Minecraft sources, but following the chain backwards from where the player is actually spawned only leads me to one spot where it's grabbing 3 int values from an NbtTree (which seems to work like a hashtable but can return multiple types instead of just one). I assume the tree is populated using the map seed but hell if I can figure out where that's happening. Specifically:

from WorldInfo.java:
code:
spawnX = nbttagcompound.getInteger("SpawnX");
spawnY = nbttagcompound.getInteger("SpawnY");
spawnZ = nbttagcompound.getInteger("SpawnZ");
If I can just find where nbttree["SpawnX"] is actually getting populated, I'm there.

PDP-1
Oct 12, 2004

It's a beautiful day in the neighborhood.
Can anyone suggest some good articles/links on how to set up a rendering engine?

My dumb gut-sense guess is that you'd send all your Draw calls to a common graphics manager component that would sort them somehow (by shader type?) and then stream the data to the actual graphics device in a post-draw step. Am I on the right track or wrong track here?

Red Mike
Jul 11, 2011

westborn posted:

He clearly does know how the seed for the terrain generation works. He was asking how the spawnpoint is determined afterwards, as Minecraft has/had the tendency to not always spawn you at the same point on the same seed.

No, he clearly doesn't. Here:

quote:

If it's random, then it wouldn't be the same every time the same seed is used.

It's pseudo-random, and it uses the same seed, so it always spawns you at the same point on the same seed.

It just uses the generator as it does when it creates the terrain. This uses x numbers from the pseudo-random series. The next 3, x+1, x+2, and x+3 are used to generate the first location it tries to put the player on. These are always the same if you use the same seed, because of how pseudo-random generators work. He clearly does not understand this, or he wouldn't be asking why they're the same every time.

And yes, you misread and thought he was arguing that it doesn't spawn at the same point for the same seed, next time read a little further.

To answer you, it uses the first 3 numbers it gets after generating the world, then, if they aren't valid, increments each one by 1 until it gets a position that works. Considering the same seed will give you the same sequence of 3 numbers after world generation every time, obviously you'll get the same position for the same seed.

HaB
Jan 5, 2001

What are the odds?

Red Mike posted:

No, he clearly doesn't. Here:


It's pseudo-random, and it uses the same seed, so it always spawns you at the same point on the same seed.

It just uses the generator as it does when it creates the terrain. This uses x numbers from the pseudo-random series. The next 3, x+1, x+2, and x+3 are used to generate the first location it tries to put the player on. These are always the same if you use the same seed, because of how pseudo-random generators work. He clearly does not understand this, or he wouldn't be asking why they're the same every time.

And yes, you misread and thought he was arguing that it doesn't spawn at the same point for the same seed, next time read a little further.

To answer you, it uses the first 3 numbers it gets after generating the world, then, if they aren't valid, increments each one by 1 until it gets a position that works. Considering the same seed will give you the same sequence of 3 numbers after world generation every time, obviously you'll get the same position for the same seed.

:psyduck:

I have no idea how this derail got so far so fast. I assure you, several condescending explanations aside, I know exactly how pseudorandom number generators work.

Picking the coordinates for spawn is obviously not as simple as "hurrrrrr get the next number from the generator" because NOTHING in Minecraft is that simple. Chunk generation uses an algorithm which goes beyond "hurf durf here's another number from the generator." It uses a bunch of constant values PLUS the random numbers and does something that eventually results in a chunk full of blocks.

It does the same thing with the spawn point, not just "grab 3 random numbers and check if that's valid, increment if it doesn't"

In my second post I said:

quote:

Yeah I know. What I mean is, Minecraft is using that seed in some equation that sets the spawn point. I'm trying to see if anyone knows what that equation is.

So FORGET I ever mentioned the words "seed", "random" and "pseudorandom". I REALIZE it's deterministic based on the seed provided to the random number generator.

So let's pretend x, y, z are numbers pulled out of thin air. Minecraft then does something to those 3 numbers that results in Spawn.X, Spawn.Y and Spawn.Z. ALL I want to know is - what is something in this instance.


And as I have already determined on my own, Minecraft loads up a hashtable (NbtTree) of all the pertinent game values, and then spends the rest of the time just doing lookups in that hashtable. I have found where it does the lookup in the table for spawn x, y, z. What I can't find is where those 3 values get populated into the hashtable.

And as far as your "answer" - can you point me to the lines in the MC source where it does that? Or even just the class file it's in?

Pfhreak
Jan 30, 2004

Frog Blast The Vent Core!
I think I see what's going on here. Most of us are abstracting your question of "How, exactly, does Minecraft generate a starting location?" into, "How do games typically generate a deterministic random set of variables?" For most of us, and for most of the questions in this thread, working at the abstraction level is pretty common for helping someone understand whatever problem they are working on.

It sounds to me like you have a project in mind ("I would like to be able to predict a start location for a given seed so I can use that value in my mod/hack/web thing/whatever.") But you haven't really talked about what it is, so it sounds like what you are asking is for general details about random world generation, of which Minecraft is an example.

ShoulderDaemon
Oct 9, 2003
support goon fund
Taco Defender

HaB posted:

I spent a few hours last night wading through the Minecraft sources, but following the chain backwards from where the player is actually spawned only leads me to one spot where it's grabbing 3 int values from an NbtTree (which seems to work like a hashtable but can return multiple types instead of just one). I assume the tree is populated using the map seed but hell if I can figure out where that's happening. Specifically:

from WorldInfo.java:
code:
spawnX = nbttagcompound.getInteger("SpawnX");
spawnY = nbttagcompound.getInteger("SpawnY");
spawnZ = nbttagcompound.getInteger("SpawnZ");
If I can just find where nbttree["SpawnX"] is actually getting populated, I'm there.

That looks like code for loading the spawn location from a save file.

World.java has getInitialSpawnLocation() which boils down to this:

code:
Create random number generator seeded using world seed.
Find all biomes within 256 cells of (0,0) which are one of the 5 valid spawn biomes.
Choose one such biome randomly with equal weight.
Let (x,y) = the center of that biome.
Repeat:
  Find the uppermost block at (x,y).
  If that block is grass, you're done.
  x += rand(64) - rand(64)
  y += rand(64) - rand(64)
The "find all biomes" step is in still-obfuscated portions of minecraft's codebase, so my 5-minute-understanding of it may be mistaken.

Edit: For me, at least, a big part of the confusion with this whole thing is that this is an algorithm I would not be shocked to find described as "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" so it's been weird that HaB seemed to want something more.

ShoulderDaemon fucked around with this message at 18:01 on Feb 18, 2012

HaB
Jan 5, 2001

What are the odds?

Pfhreak posted:

I think I see what's going on here. Most of us are abstracting your question of "How, exactly, does Minecraft generate a starting location?" into, "How do games typically generate a deterministic random set of variables?" For most of us, and for most of the questions in this thread, working at the abstraction level is pretty common for helping someone understand whatever problem they are working on.

It sounds to me like you have a project in mind ("I would like to be able to predict a start location for a given seed so I can use that value in my mod/hack/web thing/whatever.") But you haven't really talked about what it is, so it sounds like what you are asking is for general details about random world generation, of which Minecraft is an example.

I agree with you, so let me be specific about what I am trying to do.

I'm basically writing a map search/view utility. I am using Substrate which a C# library someone wrote for use with Minecraft. (Yes, I already am discussing this in a thread on the minecraft forums with the developer of Substrate). So basically, instead of needing to load a level.dat file, I am generating the map in memory from the seed. The map itself is generating perfectly. That's all Substrate built-in functions for the most part. However, the dev seems to have glossed over the setting of the initial spawn location part, because he just sets it to (0, 64, 0) and leaves it at that. So if I save my generated map and load it in MC and compare against the MC version, everything is the same except for the spawn point, because mine is always (0,0) and Minecraft is picking a different one.

My search utility will search within a certain number of chunks from the player's location, or if it's a new world, from the spawn point. So I need to be able to determine the spawn point based on the world seed - which is how everything else is determined.


ShoulderDaemon posted:

World.java has getInitialSpawnLocation() which boils down to this:

code:
Create random number generator seeded using world seed.
Find all biomes within 256 cells of (0,0) which are one of the 5 valid spawn biomes.
Choose one such biome randomly with equal weight.
Let (x,y) = the center of that biome.
Repeat:
  Find the uppermost block at (x,y).
  If that block is grass, you're done.
  x += rand(64) - rand(64)
  y += rand(64) - rand(64)
The "find all biomes" step is in still-obfuscated portions of minecraft's codebase, so my 5-minute-understanding of it may be mistaken.

Edit: For me, at least, a big part of the confusion with this whole thing is that this is an algorithm I would not be shocked to find described as "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location" so it's been weird that HaB seemed to want something more.


I want something more because I need to duplicate it elsewhere, and that description, while generally correct is useless for writing actual code. I will look at world.java to see if I can find what you're referring to. Thanks.

Edit: one step closer. the 5 biomes returned are: forest, plains, taiga and two still obfuscated ones. That's closer, tho!

HaB fucked around with this message at 18:34 on Feb 18, 2012

ZombieApostate
Mar 13, 2011
Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

:allears:
Well there's probably where the biggest confusion came from... You sound like you're trying to reverse engineer something minecraft does so you can do it exactly the same, now. Before it just sounded like "I'm making a minecraft-like, how does minecraft do this?" to which we all responded with basically "who gives a crap how minecraft does it, just do something simple".

Red Mike
Jul 11, 2011
Actually, the biggest confusion came from the first post, the following part clearly showing lack of understanding of pseudo-random number generators, whatever way I look at the phrasing.

HaB posted:

Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location"

And that's all well and good except it's not random. If I start a world with a particular seed, open it up, check my spawn coords, then delete the world and re-create using the same seed, I get the same spawn point.

Unless you suddenly moved from that question to another, what you said then has no relevance to what you ended up with as a solution now.

So it doesn't just pull 3 numbers from the generator and plug them into the coordinate system, it pulls one number from the length of the list of biomes, then keeps iterating and incrementing until it reaches a grass block. This doesn't change the fact that if you did understand how a pseudo-random generator worked at the time, the fact that it wasn't different for the same seed shouldn't have surprised you at all.

Even moreso, it should have been expected, and the question would have become 'I don't understand how it's choosing the first random position from which it starts incrementing.'

Back to the actual topic at hand, the last two should be desert and tundra, if that helps.


e: Christ almighty, I'm being pedantic and unhelpful. I'll stop this, my apologies.

Red Mike fucked around with this message at 23:31 on Feb 18, 2012

MrZig
Aug 13, 2005
I exist onl because of Parias'
LEGENDARY GENEROSITY.
I'm having an issue with figuring out decent collision detection for my 2d sprite-based Android game. I've tried implementing some pixel perfect solutions I found online, but they all seem like they're made for an image that never changes in size from the original bitmap. This obviously has some pretty big faults as I draw my images in my game at various sizes, which then get scaled according to the screen size.

I was thinking of creating a bunch of smaller boxes per sprite, each representing a part of the object. IE an arm, a head, a torso, and then the legs. This removes a lot of empty space, the alpha, from being false-detected. It's not perfect but it would be a lot closer.

Then I could use a tiered system, ie:

Check the sprite A's box against other sprite boxes, to see if they will collide at all.
If true, check each smaller box section from sprite A to sprite B and if any intersect, a collision happened.

These boxes could be scaled and placed where I want them, much easier than per-pixel. It's just very messy and not 100% accurate.

My question is, am I just totally misunderstanding pixel perfect detection? I have no experience with collision detection so I may be doing this totally wrong.

brian
Sep 11, 2001
I obtained this title through beard tax.

Unless you're constantly changing the scale, you should be able to just generate a collision bitmask (like a grid of boolean values for solidity) based off the image that you'll render to the screen after scaling, either in the constructor and/or during a setScale type property. If you're worried about memory you can cache the different sizes you make so you can reuse them too.

You can do a multiple hitbox approach and it will almost always run faster (unless pixel collision is done in hardware these days), but it's a pain to make new units and so on with, plus for objects that change animation heavily you'd have to update the hitboxes in line with the animation.

Either way when doing pixel perfect stuff you want to make sure it only does it when needed, this typically means having bounding box tests before pixel collision tests and if needed making it so only stuff that directly affects the player uses it. If you've got a lot of objects colliding a lot physics engines may be your best bet too.

MrZig
Aug 13, 2005
I exist onl because of Parias'
LEGENDARY GENEROSITY.
Thanks! I actually managed to get a PixelPerfectBitMask setup working properly, or at least good enough for now. I can start with a high res image, say 512x512, and have OpenGL refer to that for drawing, then for the bitmask I just used Android's createScaledBitmap to the object's actual size and presto, it works perfectly.

Edit: Ok apparently it still doesn't work properly. Goddamn this is hard. I don't know how to create a scaled bitmap. I tried the above method by basing it off of Android's createScaledBitmap but that doesn't seem to work either. Only works when I set BOTH objects colliding to the same exact size..

MrZig fucked around with this message at 02:52 on Feb 19, 2012

HaB
Jan 5, 2001

What are the odds?

Red Mike posted:

:words:

*sigh*

Red Mike posted:

e: Christ almighty, I'm being pedantic and unhelpful. I'll stop this, my apologies.

This. So much this.


HaB posted:

Does anyone know the method by which Minecraft generates the initial player spawn based on the seed? All I can find from googling is a general "picks a location within a few hundred blocks of (0, 0) and tries to spawn, if it fails, it increments until it finds a valid location"

And that's all well and good except it's not random. If I start a world with a particular seed, open it up, check my spawn coords, then delete the world and re-create using the same seed, I get the same spawn point.

So...does anyone know what method it's using to choose? Thanks in advance.

I bolded the only part you really needed to pay attention to. The other part was pointing out that the google results I was seeing kept saying "picks a random location blah blah" and I was pointing out that it's NOT random because I know how pseudorandom number generators work. I even said it's "based on the seed" at which point this dumb derail got started.

K. I will stop now too. Great googly moogly.

brian
Sep 11, 2001
I obtained this title through beard tax.

MrZig posted:

Thanks! I actually managed to get a PixelPerfectBitMask setup working properly, or at least good enough for now. I can start with a high res image, say 512x512, and have OpenGL refer to that for drawing, then for the bitmask I just used Android's createScaledBitmap to the object's actual size and presto, it works perfectly.

Edit: Ok apparently it still doesn't work properly. Goddamn this is hard. I don't know how to create a scaled bitmap. I tried the above method by basing it off of Android's createScaledBitmap but that doesn't seem to work either. Only works when I set BOTH objects colliding to the same exact size..

I guess make sure there aren't any offsets you're not aware of are at work and step through with a debugger or debug text write what the mask looks like internally and make sure it lines up with what you think it's meant to look like. I mean other than that it's just a case of getting the logic for the test right.

MrZig
Aug 13, 2005
I exist onl because of Parias'
LEGENDARY GENEROSITY.

brian posted:

I guess make sure there aren't any offsets you're not aware of are at work and step through with a debugger or debug text write what the mask looks like internally and make sure it lines up with what you think it's meant to look like. I mean other than that it's just a case of getting the logic for the test right.

It definitely works 100% when both objects sizes are the same, so I'm thinking offset.

I'm using the detection system from AndEngine, as can be found in the reply here:
http://stackoverflow.com/questions/7461781/android-opengl-pixel-perfect-collision-without-bitmap-data

To call it, I'm using this code

code:
	    				if (texture.mBitMask != null && enemy.texture.mBitMask != null && texture.mBitMask.collidesWith( enemy.texture.mBitMask
                                , (int)enemy.getPosition().x - (int)this.getPosition().x
                                ,(int)this.getPosition().y - (int)enemy.getPosition().y)) {
	    					DLog.d("GameObject","COLLIDED 2");
	    				}
Which works perfectly if both objects are 32x32, or 64x64 or whatever. As soon as one is a different size, the detection goes to crap and I can't really figure out why.

Adbot
ADBOT LOVES YOU

brian
Sep 11, 2001
I obtained this title through beard tax.

Well for a start you're doing test(enemy.x - this.x, this.y - enemy.y) when you want it to be test(enemy.x - this.x, enemy.y - this.y). Other than that I don't know. Just work out what should be happening on one test and what's actually happening and work out what you're doing wrong from the difference. It's really what you end up doing most of the time in game development.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply