Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Paniolo: Oct 9, 2007; Heads will roll.

Or you could just use a program like this one to generate the font texture ahead of time.

# ? Feb 22, 2011 05:35

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 00:02

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Fun anecdote on why trusting card manufacturers to write GLSL compilers instead of using some IL language or something was loving retarded:

Take a guess what happens when you try loading this up in ShaderAnalyzer:

code:

struct somestruct
{
	float hello;
};

varying vec4 something;

void main()
{
	gl_Position = ftransform();
}

If you said "Internal compilation failure" then you win the prize!

(Declaring a varying or uniform after a struct crashes their compiler)

# ? Feb 22, 2011 07:07

Vino: Aug 11, 2010

I would kill for a compatibility mode in opengl drivers to stick to the strict opengl specification even at the expense of speed, or to be able to downgrade the opengl version so that I can develop on one hardware and be reasonably assured that it will go over to other hardware well. Right now I get a strange bug where my tanks look fine on my computer but on other computers they turn brown.

Brown?!?

# ? Feb 22, 2011 07:54

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

OneEightHundred posted:

Fun anecdote on why trusting card manufacturers to write GLSL compilers instead of using some IL language or something was loving retarded:

Take a guess what happens when you try loading this up in ShaderAnalyzer:
code:
struct somestruct
{
	float hello;
};

varying vec4 something;

void main()
{
	gl_Position = ftransform();
}
If you said "Internal compilation failure" then you win the prize!

(Declaring a varying or uniform after a struct crashes their compiler)

It's hardly the Spec's fault that AMD tools are a POS...

# ? Feb 23, 2011 14:04

Scaevolus: Apr 16, 2007

ATI really doesn't like OpenGL for some reason.

# ? Feb 23, 2011 17:44

pseudorandom name: May 6, 2007

I wonder if that reason is related to the ATI GPU in the Xbox 360.

# ? Feb 23, 2011 19:04

pogothemonkey0: Oct 13, 2005; God I fucking love Diablo 3 gold, it even paid for this shitty title

I'm just fooling around in XNA and probably won't get anywhere with it. I have some questions about hex grids. They're pretty trivial to represent as 2d arrays, but I'm a little unsure how to generate the art tiles. Presumably I'll be using a spritesheet (even though there will end up being a ton of transparency) but I suppose I need to figure out how big I want each tile to be.

Is there any motivation not to use some arbitrary tile width/height?

# ? Feb 23, 2011 21:21

SlightlyMadman: Jan 14, 2005

Keep in mind that sub-cell rendering and border overlap will make some multiples easier than others, but it depends entirely on your purposes which are which.

# ? Feb 23, 2011 22:29

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Hubis posted:

It's hardly the Spec's fault that AMD tools are a POS...

It's the spec's fault that they decided that vendors whose OpenGL drivers have not historically been of the highest quality should also be responsible for writing fully-functional compilers. As opposed to, say, using a SSA IL language that would be very difficult to gently caress up and would let users/developers decide for themselves what shading language they wanted to use.

I'm not absolving NVIDIA from this either, NVIDIA has the opposite problem where tons of stuff that breaks spec and should error (i.e. implicit int/float casting) doesn't even throw a warning, but does error once you try deploying to ATI.

pseudorandom name posted:

I wonder if that reason is related to the ATI GPU in the Xbox 360.

If it had to do with anything other than mere price, then it probably had more to do with NVIDIA trying to gently caress Microsoft over on chip prices with the original Xbox.

pogothemonkey0 posted:

(even though there will end up being a ton of transparency)

If using shapes other than quads isn't an option, you can still use sprites with unusual packings by assigning each sprite a unique alpha value and using alpha test (set to equal) or texkill.

OneEightHundred fucked around with this message at 17:36 on Feb 24, 2011

# ? Feb 24, 2011 00:28

pseudorandom name: May 6, 2007

OneEightHundred posted:

If it had to do with anything other than mere price, then it probably had more to do with NVIDIA trying to gently caress Microsoft over on chip prices with the original Xbox.

I've never heard that story -- was it before or after Microsoft made nvidia discard entire production runs of the northbridge (?) that was vulnerable to DRM hacking and then eat the losses?

# ? Feb 24, 2011 03:46

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

pseudorandom name posted:

I've never heard that story -- was it before or after Microsoft made nvidia discard entire production runs of the northbridge (?) that was vulnerable to DRM hacking and then eat the losses?

http://www.eetimes.com/electronics-news/4094562/Microsoft-takes-Nvidia-to-arbitration-over-pricing-of-Xbox-processors

I might have the details slightly confused, but they did argue over the chip pricing for a bit and I believe it was over an agreement where Microsoft thought NVIDIA was obligated to reduce the chipset prices after a while, but NVIDIA tried using some contract loophole to continue charging them a higher amount.

# ? Feb 24, 2011 07:33

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

OneEightHundred posted:

It's the spec's fault that they decided that vendors whose OpenGL drivers have not historically been of the highest quality should also be responsible for writing fully-functional compilers. As opposed to, say, using a SSA IL language that would be very difficult to gently caress up and would let users/developers decide for themselves what shading language they wanted to use.

I was thinking about your view here with a especially cynical state of mind today. Wouldn't an intermediate language just procrastinate the moment when the driver vendor gets to gently caress up? Maybe they don't blow it in a compiler, but instead they'll get to blow it when they screw up how they handle the intermediate language.

Events of late have been leading me to believe crappy developers will find new and innovative ways to write crappy code when given the chance.

# ? Feb 24, 2011 21:11

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Rocko Bonaparte posted:

Wouldn't an intermediate language just procrastinate the moment when the driver vendor gets to gently caress up?

I can name at least 4 separate issues that lead to actual compilation failures which are pre-code-generation, none of which happen consistently across vendors, 3 of which are still current. I can't help but think that if other developers were writing software they do nothing but output IL, the quality of the results would be markedly better and more consistent, while making the shaders actual "write once, run anywhere" instead of the non-compliance shitfest it is now. It would also probably mean more stuff in the vein of Cg, i.e. shading languages that work even across APIs.

Not to say there weren't problems with the assembly-esque language they used to use (which could occasionally cause BSODs on ATI cards), but it really did work a lot more often and more consistently.

OneEightHundred fucked around with this message at 00:14 on Feb 25, 2011

# ? Feb 25, 2011 00:01

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

OneEightHundred posted:

I can name at least 4 separate issues that lead to actual compilation failures which are pre-code-generation, none of which happen consistently across vendors, 3 of which are still current.

Perhaps the problem is not that the standard said "write your own compilers" but rather that they didn't make some sort of edge-cases-considered test shader file(s) with which to verify that the compiler works properly.

Though it's understandable when the problem is things coming up in unusual orders - Microsoft's own C++ "#pragma push_macro" breaks things in their own compiler if used inside a class declaration.

Not so understandable when the same problem comes up again in a later version - it seems like there should be a set of standard "your compiler must handle these" shader files from whoever sets the standards, and when someone screws up the standard in a way that doesn't break anything in those files, the files get updated to prevent the same cock-up from recurring in later versions.

# ? Feb 25, 2011 00:43

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

It's more like a problem of, if there are 3 different compilers with 1 target, then only one of those compilers has to actually work, and if one breaks then you can just use a different one. Even if all three manage to be broken somehow, you only really have to deal with the faults of one instead of having to deal with the faults of all of them at once.

The "uniform after struct = crash" thing isn't even an edge case, because you can have uniforms that are structs, so if they missed that then it means they weren't even regression-testing that basic feature.

# ? Feb 25, 2011 00:56

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

OneEightHundred posted:

It's more like a problem of, if there are 3 different compilers with 1 target, then only one of those compilers has to actually work, and if one breaks then you can just use a different one.

Yeah, but like Rocko said, if there was one compiler and then they all had to interpret the same intermediate language you'd just get the same problems deferred. Having individual compilers and a better testbed would alert to problems in the driver sooner. Though I suppose having individual intermediate-language-interpreters with a good testbed would work just as well. My point still stands that it's not the "three compilers" causing poo poo-code problems, it's the absence of a decent test suite from the people who make the standards. (And poor coding of course, but poor coding should be assumed, decent test suite is how you solve it.)

Also I'd guess the individual compilers method might have something to do with working around patent issues or something? It means the different companies' chipsets can work in different ways to the same goal while still all achieving the best performance they can, without stepping on each others' design toes. (Though that sort of legal wrangling is entirely stupid and frustrating from everyone's perspective but lawyers', it might still be necessary.)

Even if not that, there's the possibility that some performance gain might be squeezed out of the compilation that would be lost to an intermediate language.

# ? Feb 25, 2011 03:07

Chainclaw: Feb 14, 2009

I'm sure this will be useful to someone here. I've been fiddling with Atari development for a few years in my free time (straight Assembly, as well as Batari Basic), and it was fun, but I really wanted to get into some NES development. NES homebrew information was sparse and hard to find just a good demo with things happening. I learn best by poking around a simple, working demo. Eventually I found this: http://nesdev.parodius.com/bbs/viewtopic.php?t=7099&postdays=0&postorder=asc&start=0
Someone got a C compiler working for the NES, and included a demo with scrolling, player movement, simple physics, sound, a title screen. Basically a lot of components of getting a game up and running. I've already done enough straight assembly development to know I prefer working a level or two up, and C is a nice middle ground of speed of development vs building code that can run quickly on target.

I haven't been spending too much time on this yet, averaging maybe 2 hours a week, but I make some decent progress in the little time I do spend on this, which is great.

# ? Feb 26, 2011 21:16

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Have you considered homebrew DS? There's probably more people who'll play a DS game if you make a decent one, and there's a reasonably functional C library and documentation for it, and even an emulator with debugger (no$gba is the emulator, I think the version with the debugger costs a few bucks).

# ? Feb 26, 2011 21:26

Scaevolus: Apr 16, 2007

I like the optimization notes for KNES:

quote:

Compile with the �-Cl� switch, this makes local parameters static. Otherwise they�re allocated from the CC65 software emulated stack, which is understandably very slow. One drawback to this is that every single temporary variable will now take a byte in RAM, even if it�s used very rarely. It might be a good idea to have some generic temporary global variables for that purpose instead.
Use #pragma bss-name and/or data-name to place variables on the zero page.
Avoid passing parameters to functions � use global variables. If you need parameters, use the __fastcall__ calling convention, which can pass two byte variables in the A and X registers.
Use the optimizer (�-Oirs� switch) BUT be aware that it might in some cases produce broken code. One such case is when you read the controllers by strobing $4016, then reading it eight times. The first read is optimized away. Of course when you�re using this library you can simply use read_joy().
Don�t use structs or at least be very careful with them! Instead of stuff like struct Foo { int a; char b; }; struct Foo foos[NUM_FOOS]; try using struct Foo { int a[NUM_FOOS]; char b[NUM_FOOS]; }; struct Foo foos; for performance.

I never considered how annoying it is to compile C to 6502 code.

roomforthetuna posted:

Have you considered homebrew DS? There's probably more people who'll play a DS game if you make a decent one, and there's a reasonably functional C library and documentation for it, and even an emulator with debugger (no$gba is the emulator, I think the version with the debugger costs a few bucks).

no$gba is dead, and there's no way to get the debugger version anymore.

DeSmuME is still quite active, and that's what a lot of DS homebrew devs use.

Scaevolus fucked around with this message at 21:32 on Feb 26, 2011

# ? Feb 26, 2011 21:30

Chainclaw: Feb 14, 2009

roomforthetuna posted:

Have you considered homebrew DS? There's probably more people who'll play a DS game if you make a decent one, and there's a reasonably functional C library and documentation for it, and even an emulator with debugger (no$gba is the emulator, I think the version with the debugger costs a few bucks).

My day job has been making DS games for 6 years now, so there are many reasons I won't do homebrew DS. I see your point though, there are some awesome homebrew DS stuff, and it is really easy to get up and running. Also I'm coding on a Dell Mini 9 most of the time, so I want to keep compile times to a minimum, and NES stuff is great for that.

# ? Feb 27, 2011 09:35

Natalie Portmanteau: Aug 19, 2010; by T. Finn

Just saw Peter Molyneux. Cool!

# ? Feb 28, 2011 18:21

monsterland: Nov 11, 2003

Vino posted:

I would kill for a compatibility mode in opengl drivers to stick to the strict opengl specification even at the expense of speed, or to be able to downgrade the opengl version so that I can develop on one hardware and be reasonably assured that it will go over to other hardware well. Right now I get a strange bug where my tanks look fine on my computer but on other computers they turn brown.

Brown?!?

I've had some terrible OpenGL problems too. My work machine wouldn't show ammo counters, while home machine did. Same exact compilers, SDL versions, everything. It drove me NUTS.

Then I stopped using the "glSOMETHING4ub" command for setting alpha, and shifted to 3ub version.

It fixed it.

In short, I said goodbye to alpha blending. Removed it from my core rendering routines. The only thing I can rely on is basic blitting and coloring of textures onto 2D plane.

# ? Mar 1, 2011 00:48

Vino: Aug 11, 2010

As much as I like OpenGL, DirectX definitely has the right idea when they standardize each version separately. It makes it a pain to update to a new version, but maintaining code is much easier.

I figured out the the brown tanks are on ATI cards only. I posted on my twitter: "Special promotion with AMD: Users of ATI cards will get a FREE special BROWN Digitank!"

Now it's a feature!

# ? Mar 1, 2011 00:53

speng31b: May 8, 2010; Can't post for 3 hours!

It's been awhile, but couldn't you use something like GLEW to make your life easier when it comes to figuring out which glXXX commands are supported? Granted it's a pain in the rear end, but I always thought "proper protocol" was to make sure that every command you would be using (or some equivalent variant) was supported at the start.

# ? Mar 1, 2011 01:30

Vino: Aug 11, 2010

Stuff like glew and glfw makes it easier but there's still the issue of different shader language implementations, different semantics of what's allowed and when, weird problems on different machines that do or don't support this mishmash of extensions. I'd like to be able to write one code-path and have it work everywhere.

# ? Mar 1, 2011 02:25

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Is there a good online primer about different model animation file formats and their limitations? I was toying around with loading and animating an MD2 model in Irrlicht and found it was a bit counter-intuitive. There is some concept of fixed actions that use a compiler enumeration, but it looks like there isn't something in the format for defining arbitrarily different animations. I assume most of the formats have their little quirks like that, so I hoped there was a programmer's primer for these so I can go in understanding all their little limitations.

# ? Mar 1, 2011 03:36

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Rocko Bonaparte posted:

Is there a good online primer about different model animation file formats and their limitations? I was toying around with loading and animating an MD2 model in Irrlicht and found it was a bit counter-intuitive. There is some concept of fixed actions that use a compiler enumeration, but it looks like there isn't something in the format for defining arbitrarily different animations. I assume most of the formats have their little quirks like that, so I hoped there was a programmer's primer for these so I can go in understanding all their little limitations.

What kind of model do you need, and do you have control over what gets exported or are you salvaging existing assets.

# ? Mar 1, 2011 06:35

Paniolo: Oct 9, 2007; Heads will roll.

Rocko Bonaparte posted:

Is there a good online primer about different model animation file formats and their limitations? I was toying around with loading and animating an MD2 model in Irrlicht and found it was a bit counter-intuitive. There is some concept of fixed actions that use a compiler enumeration, but it looks like there isn't something in the format for defining arbitrarily different animations. I assume most of the formats have their little quirks like that, so I hoped there was a programmer's primer for these so I can go in understanding all their little limitations.

If you just want to get some pre-existing assets into your program I'd recommend using assimp as an importer and rolling your own model file format based on your own needs. Assimp will deal with the quirks of the various formats it imports and put everything in a standardized data structure for you.

# ? Mar 1, 2011 08:37

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Yeah use assimp in general if you can, it's pretty much a godsend as far as not having to write loader boilerplate all over again. As far as formats: If you can use COLLADA or FBX as the export format, please do. Those are the only two non-specialized export formats that essentially support everything. The drawback is that they are hard to parse, but if you're using someone else's parser then who gives a poo poo?

Of the specialized formats:
- MD2 has terrible precision and experiences "boiling" artifacts on high-poly models. You should probably not use it.
- MD3 supports attachment points and is otherwise a pure vertex format, but it's easy to parse and better than MD2 for almost all scenarios.
- Epic PSK/PSA, Source SMD, and Id MD5 are roughly identical capability-wise. All three are simple skeletal formats that support simple orientation/position based skinning on one mesh tracked by frame with multiple weights per vertex. Of them, PSK/PSA are probably ideal as SMD doesn't store framerate and MD5 duplicates points across textures.

OneEightHundred fucked around with this message at 20:50 on Mar 1, 2011

# ? Mar 1, 2011 20:48

Zero The Hero: Jan 7, 2009

I've been reading about state-based organization from this article: http://lazyfoo.net/articles/article06/index.php and I have some questions.
The first way I would think to use this would be for a 2D RPG, or something. So, corrrect me if I'm wrong, but you would make a separate state for each city or house or any separate screen, really. Then more for the battle screen, But you would have tons of those in an RPG, and it seems like things would get REALLY cluttered, REALLY quickly. But they're making separate classes for each screen. Wouldn't it make more sense to just have one class for battle screens and one for when you're walking around in an overworld or city or whatever, and just have the classes flexible enough to handle different screens? Is it just so they can have different content for the handle_events function?

And, is this strategy actually used often? Or is this just a waste of time?

# ? Mar 2, 2011 02:15

Null Pointer: May 20, 2004; Oh no!

Zero The Hero posted:

Wouldn't it make more sense to just have one class for battle screens and one for when you're walking around in an overworld or city or whatever, and just have the classes flexible enough to handle different screens?

Yes. I assume they implemented it this way for pedagogical reasons.

This idea is used almost universally and it is extremely worthwhile to understand. The specific implementation doesn't really matter as long as you can live with it. I think GWT has a particularly elegant solution, which might be worth emulating.

# ? Mar 2, 2011 04:49

AntiPseudonym: Apr 1, 2007; I EAT BABIES

Zero The Hero posted:

I've been reading about state-based organization from this article: http://lazyfoo.net/articles/article06/index.php and I have some questions.
The first way I would think to use this would be for a 2D RPG, or something. So, corrrect me if I'm wrong, but you would make a separate state for each city or house or any separate screen, really. Then more for the battle screen, But you would have tons of those in an RPG, and it seems like things would get REALLY cluttered, REALLY quickly. But they're making separate classes for each screen. Wouldn't it make more sense to just have one class for battle screens and one for when you're walking around in an overworld or city or whatever, and just have the classes flexible enough to handle different screens? Is it just so they can have different content for the handle_events function?

And, is this strategy actually used often? Or is this just a waste of time?

edit: I'm a moron that should read the drat link properly before posting.

Yeah, setting up each room/battle individually is a bad idea. Your best bet would be to just have generic states (Such as BattleState/OverworldState) that load all of their specifics (Such as enemy placement, background image, etc) from data or even just generate it procedurally.

editedit: Also, I can't see any reason to use state IDs (Except for simplicity). It will probably come down to what level of C++ you're comfortable with, but either using a hash_map of pre-created states or just creating/deleting states on a per-use basis would be more malleable in the long-run. Your state machine shouldn't need to know any game-specific details about the states it's managing.

AntiPseudonym fucked around with this message at 06:09 on Mar 2, 2011

# ? Mar 2, 2011 05:52

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

OneEightHundred posted:

Of the specialized formats:
- MD2 has terrible precision and experiences "boiling" artifacts on high-poly models. You should probably not use it.
- MD3 supports attachment points and is otherwise a pure vertex format, but it's easy to parse and better than MD2 for almost all scenarios.
- Epic PSK/PSA, Source SMD, and Id MD5 are roughly identical capability-wise. All three are simple skeletal formats that support simple orientation/position based skinning on one mesh tracked by frame with multiple weights per vertex. Of them, PSK/PSA are probably ideal as SMD doesn't store framerate and MD5 duplicates points across textures.

Thanks all for this and everything else. I guess I'll rant about what I'm experiencing since I think there's a question about what it is I'm trying to actually accomplish.

I thought I'd open up some models from the jDoom resource pack and make them do a little dance or something. I just knew it was a place that had lots of free models that I had seen before in years past. They are all stored in MD2 files. Using Irrlicht, I can load in and skin, say, the chain gun guy fine and dandy. Except that he has no gun. If I look at the model in Blender, it is there. Or at least the vertices are there; I couldn't get it to show any of the model(s) textured. Import the same file in Irrlicht, and it's gone. So I was trying to figure out how to attach the drat thing or get it to show up or what.

To make things more fun, Irrlicht seg faults when I try to load the gun model too. I haven't figured out why.

I'm assuming they made the gun removable to make it available as an item to pick up after the player kills the monster. But I see from the format differences is that it's a real pain in the rear end to attach it. I guess it's more of an illusion than actually attaching it. It's just coincidentally floating in the spot of the model's hand, as opposed to something like bones where the engine knows there is really a relationship between the main model and the gun.

Since I thought doing this would actually be easier I have concluded it's not helping and have about given up. So then I figured maybe I could model something really simple in Blender, like a cube person or something. Except that all the modeling videos are done by people talking through retainers that assume you already know how to use Blender, and basically imply you already know how to do everything they're showing anyways. So I've gotten a little bit frustrated. I have done level editing in Radiant before so I thought I'd have some basis for this, but I can't even figure out what views and magic keys I need to make a model with some basic animations.

And all this before I really write any code!

# ? Mar 2, 2011 20:15

Nalin: Sep 29, 2007; Hair Elf

Rocko Bonaparte posted:

To make things more fun, Irrlicht seg faults when I try to load the gun model too. I haven't figured out why.

You should post the model on the Irrlicht forums so the crash can be fixed.

Irrlicht can load many different types of model formats. This is nice since you can use whatever format you desire, but it also has the unfortunate side effect where it doesn't fully support any format. Searching the Irrlicht forums can reveal a bunch of information on what does and doesn't work for certain model formats. From what I remember, one of the best supported animated formats is the .b3d format.

Also, the Irrlicht animation system is currently kind of limited. You can either play a specific MD2/MD3 animation, or you can set a range of frames to loop through for the other animation formats. Named animations aren't supported yet (although there is a thread discussing options on how to implement that feature.)

# ? Mar 2, 2011 20:36

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Rocko Bonaparte posted:

It's just coincidentally floating in the spot of the model's hand, as opposed to something like bones where the engine knows there is really a relationship between the main model and the gun.

MD2 does not actually support attachments, if you can figure out a way to open up the models for Quake 2 then what you'll see is that the weapon models are actually fully animated to sync up with the player models. They basically float around in space, and when the engine renders them, it puts both models on the same location at the same frame.

MD3 does support attachment points, all skeletal formats do as well.

# ? Mar 2, 2011 21:11

HaB: Jan 5, 2001; What are the odds?

Rocko Bonaparte posted:

Since I thought doing this would actually be easier I have concluded it's not helping and have about given up. So then I figured maybe I could model something really simple in Blender, like a cube person or something. Except that all the modeling videos are done by people talking through retainers that assume you already know how to use Blender, and basically imply you already know how to do everything they're showing anyways. So I've gotten a little bit frustrated. I have done level editing in Radiant before so I thought I'd have some basis for this, but I can't even figure out what views and magic keys I need to make a model with some basic animations.

And all this before I really write any code!

Can't help with your model loading/animating problem, but having ZERO 3D modelling experience myself, I set out to learn Blender and found this, which worked pretty drat well:

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

I dunno about all the way to "Pro" but I definitely go from "Noob" to "Passable" using that.

# ? Mar 4, 2011 01:26

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

HaB posted:

Can't help with your model loading/animating problem, but having ZERO 3D modelling experience myself, I set out to learn Blender and found this, which worked pretty drat well:

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

I dunno about all the way to "Pro" but I definitely go from "Noob" to "Passable" using that.

This looks very complete. I might have to just hush up for a few days and read through a lot of that. I'm assuming after the smoke clears I can make a decent enough box person that I can run through various abusive animations in a 3d engine without much fuss. I have ton of tabs open where I just went off on tangents on things like adjusting the view or tweaking vertices because I couldn't find it all in one spot. This looks pretty much like what I needed.

# ? Mar 4, 2011 06:23

nibe: Feb 23, 2008

This was a godsend for my Blender learning:

http://wiki.blender.org/index.php/Doc:Tutorials/Animation/BSoD/Character_Animation

It takes you step by step through creating and animating a humanoid model. It assumes no prior knowledge and teaches a lot of the basic hotkeys and functionality. One thing it doesn't cover is unwrapping a mesh for texturing, if you want to do that. Blender has a number of unwrapping algorithms, the only one I've found useful is the basic "Unwrap" one. First you have to specify seams by selecting edges and pressing Ctrl+E -> Mark Seam. Then select all and press U -> Unwrap. You need a "UV/Image Editor" window open to see the unwrapped mesh.

nibe fucked around with this message at 10:16 on Mar 4, 2011

# ? Mar 4, 2011 10:12

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Speaking of Blender, is there an alternative that doesn't have such a lovely unintuitive interface?

I haven't used it in a few months and I wanted to make some models, but I'm dreading relearning it because it was so painful the first time.

# ? Mar 4, 2011 17:20

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 00:02

Bizarro Buddha: Feb 11, 2007

Blender 2.5 is a lot better than 2.4 was, they've completely redone the interface.

# ? Mar 4, 2011 17:32

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »