|
Or you could just use a program like this one to generate the font texture ahead of time.
|
# ? Feb 22, 2011 05:35 |
|
|
# ? May 12, 2024 10:31 |
|
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:
(Declaring a varying or uniform after a struct crashes their compiler)
|
# ? Feb 22, 2011 07:07 |
|
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 |
|
OneEightHundred posted:Fun anecdote on why trusting card manufacturers to write GLSL compilers instead of using some IL language or something was loving retarded: It's hardly the Spec's fault that AMD tools are a POS...
|
# ? Feb 23, 2011 14:04 |
|
ATI really doesn't like OpenGL for some reason.
|
# ? Feb 23, 2011 17:44 |
|
I wonder if that reason is related to the ATI GPU in the Xbox 360.
|
# ? Feb 23, 2011 19:04 |
|
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 |
|
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 |
|
Hubis posted:It's hardly the Spec's fault that AMD tools are a POS... 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. pogothemonkey0 posted:(even though there will end up being a ton of transparency) OneEightHundred fucked around with this message at 17:36 on Feb 24, 2011 |
# ? Feb 24, 2011 00:28 |
|
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 |
|
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? 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 |
|
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. 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 |
|
Rocko Bonaparte posted:Wouldn't an intermediate language just procrastinate the moment when the driver vendor gets to gently caress up? 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 |
|
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. 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 |
|
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 |
|
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. 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 |
|
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 |
|
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 |
|
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. 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 |
|
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 |
|
Just saw Peter Molyneux. Cool!
|
# ? Feb 28, 2011 18:21 |
|
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. 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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.
|
# ? Mar 1, 2011 06:35 |
|
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 |
|
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 |
|
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 |
|
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? 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 |
|
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. 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 |
|
OneEightHundred posted:Of the specialized formats: 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 |
|
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. 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 |
|
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. MD3 does support attachment points, all skeletal formats do as well.
|
# ? Mar 2, 2011 21:11 |
|
Rocko Bonaparte 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.
|
# ? Mar 4, 2011 01:26 |
|
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:
|
# ? Mar 4, 2011 06:23 |
|
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 |
|
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 |
|
|
# ? May 12, 2024 10:31 |
|
Blender 2.5 is a lot better than 2.4 was, they've completely redone the interface.
|
# ? Mar 4, 2011 17:32 |