|
So I started reading this thread at the beginning a few days ago, but once the age of the first posts registered with me, and everyone was still talking about XNA 2.0 (and I just grabbed 4.0) I skipped ahead to posts from this year at least. Anyway....some great advice so far from what I've seen. I have dabbled in game programming before, but the last 4-5 years have been doing almost exclusively .NET CRUD web apps in C#/Linq/etc. I have conceived what seems like a solid idea for a game, and based on some things in this thread - it has mutated somewhat into improvements over the original concept. So after having the "write a game, not an engine" mantra firmly wedged into my wazoo  I grabbed Unity this morning and worked through the 2D platformer tutorial and will be working through the 3D one as well.As an aside: I have the following to say about Unity: It's very very slick, and I assume once I get into actually scripting my own game logic for the prototype I will feel like I'm getting more education out of it. But really - using prefabs and ready made scripts and such I don't feel like I'm learning a THING so far about actual game architecture. I get how it all works in Unity. You can attach Thing A to Thing B, and set properties on both Things that get updated, etc. But I dunno - it almost feels like just a more complicated version of GameMaker or something built for non-programmers. That being said, I think it will be a useful tool to prototype my game - and assuming the idea is sound - go from there. Another maxim I have picked up in this thread is "what engine should I use for my game?" is best answered by "depends on your game." So here's what I'm shooting for: Turn-based strategy game, with 2 main "interfaces": World Map - sort of like Risk. Top down (or fixed angle) camera, movement only in XY axes. The map is divided into territories, and at one end you have a base which generates new units at a rate which depends on how much territory you actually own. The only functions which are handled here are: - moving units from territory to territory (either by group or individuals) - queuing up which units you wish to build Since the view is from a fixed height and encompasses the entire (scrollable) world map - I may not even bother with 3d models here save for buildings and maybe not even then. Everything is designed to just be representational in a strategic planning sort of way. Anyway, when each player has had a turn moving Units on the World Map, any territory which they BOTH have units in is considered "contested" which leads to the other interface: Battle Screen - sort of like Battle Chess or even Archon if you can remember that far back. 3D space, player controlled camera. 3D models for each Unit. The combat is based on a grid, so the grid would be overlaid on top of the terrain, and each player is allowed to place their units on their own side of a Neutral Zone in the middle of the playfield. Once both players have placed units, the skirmish begins. For each player's turn, each unit can either Move or perform an Action (attacking, special ability, etc). Rinse-repeat until one side is defeated, at which point that Territory is now under control of the winner. Return to the World Map and if there are any contested territories left, the winner picks where the next skirmish occurs, until they are all decided. Play then returns to the World Map where the strategy turn occurs. The nice thing about it all being turn-based is: aside from models colliding with the floor, I don't need much at all in the way of collision detection. All attacks/abilities have a range and area of effect measured in grid squares. If say an explosion has a radius of 5 squares from the target square, then anything within that area of effect is affected. Easy peasy. SO - all that being said, and assuming the prototype doesn't suck and it's something I wish to proceed forward with - can anyone recommend an engine that might be suitable for handling that kind of stuff? And before I get berated for trying to do too much: my plan is to prototype the World Map first, with only ONE type of Unit, with any combats being resolved by toss of the dice. Then I will prototype Combat, again with only ONE unit type. I use an Iterative approach in my daytime programming job, so will be shooting for the same thing here. Baby steps. Hell, a friend and I are going to sit down and tweak the combat rules using miniatures and dice before I do ANYTHING else. I understand my goals are lofty ones. 
|
#
?
Feb 15, 2011 19:27
|
|
|
|
| # ? May 11, 2024 12:03 |
|
|
I'm not sure I understand your complaint - Unity is too easy? Is there something about your game idea that you feel Unity can't do? If there's no part it can't do, and the performance will be fine (which obviously it will for a turn-based game), and you find it easy, then surely the engine you should use is Unity? I was eyeing Unity for my next project, but since I want to use a custom input device I suspect I'd need the expensive super-pro version that supports custom plugins, which is an unfortunate limitation that counts against it for me, but I don't see anything like that in your idea.
|
|
#
?
Feb 15, 2011 19:47
|
|
|
Bob Morales posted:Flickers a bunch but it works fine for me in FF3 and Chrome in Fedora 14 (64-bit) Thanks for pointing that out. I looked it up and found a buffering technique with two canvases. I updated it - would you mind checking it out and seeing if the flicker has gone away? EDIT: Or anyone else, if you see flickering or other issues in Chrome/Safari/Firefox. http://www.stephanwozniak.com/production/shooter/ hedgecore fucked around with this message at 20:01 on Feb 15, 2011 |
|
#
?
Feb 15, 2011 19:55
|
|
|
roomforthetuna posted:I'm not sure I understand your complaint - Unity is too easy? Wasn't really a complaint so much as an observation. I guess I will see how well Unity performs for what I want to do when I get far enough along. I guess I'm just used to being a coder - so the drag and drop thing is sort of alien to me.
|
|
#
?
Feb 15, 2011 20:52
|
|
|
Using Unity extensively will probably teach you more about how a good engine architecture can allow not only a wide variety of projects but also make doing them all a lot easier. I don't think you'll find many people who find Unity's component approach anything but great, especially when it allows the performance centric parts to be done in an optmised fashion without impacting the general usage of the engine. There's nothing inherent in Unity that restricts any particular usage apart from very cutting edge API specific stuff that isn't yet supported or something that's only available in Unity Pro like direct access to the graphics library or C++ plugins for special APIs (like webcam augmented reality stuff or custom peripherals and so on). The shortfalls of Unity are generally for edge case stuff where you'd need the source, like porting to unsupported devices or replacing the physics engine or sound library, although for the latter there may be C# ports that can be used easily due to the use of Mono.
|
|
#
?
Feb 15, 2011 22:06
|
|
|
Ah, I haven't actually tried Unity myself, so yeah, I agree that a drag-and-drop level of easiness would be pretty disturbing even if the output is perfectly fine. I'd also be a little afraid of 50MB of download required for a plain Tetris clone that should be measured in kilobytes, based on that. Since you've played with it, would that fear be justified? Are your tutorial binaries large / large DLLs required?
|
|
#
?
Feb 15, 2011 22:07
|
|
|
Where'd this 50mb number come from? My windows build of a project with around 1mb of assets was 4.88mb, the web build was only 400kb which confuses me given the assets size and the mac build was double the windows build because it contained both an x86 and a PPC build. If you're not aware Unity has a web plugin system too that reduces the need to include the base engine stuff as it's already on the user's PC. There's even Unity web games on Kongregate and some other flash portals now. I'm not intentionally trying to evangelise for it, it's just there seems to be a lot of misconceptions based on experiences with other engines that simply don't apply. I mean WildTangent really buggered up the general view of non-flash browser plugins for game development so I can understand people being weary about that side of things but the idea that game development tools can't be efficient and easy to use is horribly outdated.
|
|
#
?
Feb 15, 2011 22:26
|
|
|
He might be talking about the unity plug-in that is needed to play the games. I'm a big fan of Unity, but I feel that it has some real flaws in it. I will say that I haven't had the chance to play around with Unity 3 yet, so I can't talk about it, but I recall Unity 2 having some strange and occasionally tedious issues. I still recommend it for any small to medium sizd project, especially if you don't feel like building a physics engine.
|
|
#
?
Feb 15, 2011 22:42
|
|
|
HaB posted:Wasn't really a complaint so much as an observation. I guess I will see how well Unity performs for what I want to do when I get far enough along. I guess I'm just used to being a coder - so the drag and drop thing is sort of alien to me. I'd suggest deciding if you want this project to be about making a game, or programming a game. Because if you're turned off by not writing code, then my advice is to just work on a programming project, like a hobby engine or tech demo. If you actually want to make a finished game then use Unity or GameMaker or mod an existing game or whatever is at your disposal, because actually making a game is such an enormous amount of work that an individual simply cannot afford to not take every shortcut possible.
|
|
#
?
Feb 15, 2011 22:52
|
|
|
Unity's flaws are generally related to doing group projects without (and sometimes with) the Asset Server, it's incredibly hard to collaborate on the same project since you can't just diff the Unity project file. With the asset server (for which client licenses are usually prohibitively expensive) it's a lot easier since prefabs and assets are versioned and whatnot correctly. The other main issue is that PhysX is kind of a giant pile of poo poo for 2D stuff because there's no reliable way to limit stuff to a 2D plane without running into some bizarre issue at some point. It's definitely not my first choice for 2D projects, but there's nothing to stop you from implementing Box2D or using whatever C# port of it is available. In general the problem areas of Unity are the stuff that's in there to help that have bugs or don't have the thing you want in them, but there's usually a way of implementing whatever you wanted yourself and side stepping that stuff. That said the lack of a switch to remove some stuff completely from the end binary (like PhysX) is annoying.
|
|
#
?
Feb 15, 2011 22:57
|
|
|
brian posted:Where'd this 50mb number come from? Around 3MB of inflation isn't too bad - beats XNA once all the junk required to get an XNA game running is included! quote:That said the lack of a switch to remove some stuff completely from the end binary (like PhysX) is annoying.
|
|
#
?
Feb 15, 2011 23:31
|
|
|
hedgecore posted:Thanks for pointing that out. I looked it up and found a buffering technique with two canvases. I updated it - would you mind checking it out and seeing if the flicker has gone away? Works fine in Chrome and FF Beta on Mac OS X. Works in FF 3.6 but of course it's slower. How are you doing that LCD-style blur effect?
|
|
#
?
Feb 16, 2011 00:57
|
|
|
Paniolo posted:I'd suggest deciding if you want this project to be about making a game, or programming a game. Because if you're turned off by not writing code, then my advice is to just work on a programming project, like a hobby engine or tech demo. If you actually want to make a finished game then use Unity or GameMaker or mod an existing game or whatever is at your disposal, because actually making a game is such an enormous amount of work that an individual simply cannot afford to not take every shortcut possible. Well, I will probably go ahead with prototyping on Unity at least. If the game ends up being awesome enough to warrant going with a more ground-up route then we can address that when the time comes. I'm working with one other developer and are talking to a few artist friends. Both of us devs have 10+ years of C# experience, but he has ZERO game programming experience and as I've said - I've only dabbled. I'm hoping that doing it in Unity and getting it up and working will give us some idea of how we might implement on our own, should we go that route.
|
|
#
?
Feb 16, 2011 01:02
|
|
|
Is there a text library for OpenGL that doesn't involve wanting to throw things at other things really, really hard? I was hoping to render some text for some charting code, so I didn't want to go grab some full-fledged 3d engine just for that. I started with OpenGL's own rasterization stuff. It was fine enough until the coordinates for the text went off the screen, so the rest of the text would just vanish. I started screwing with FTGL and got a texture font up. Just for giggles I decided to push it and sent it a newline. It just put a garbage character there and blew it off. So let's say maybe I wanted to render a box worth of text that might move around and even only be halfway on any particular part of the screen. Is there an OpenGL library that'll do the job without pulling in a bunch of stuff?
|
|
#
?
Feb 17, 2011 08:25
|
|
|
Rocko Bonaparte posted:Is there a text library for OpenGL that doesn't involve wanting to throw things at other things really, really hard? I was hoping to render some text for some charting code, so I didn't want to go grab some full-fledged 3d engine just for that. I went the following way: 1) Used SDL 2) Figured how to draw a 2D image using SDL's OpenGL, in the fashion of a DirectDraw "blit". Admittedly, gathering this information off half-assed tutorials by bits and pieces was a pain, and, chances are, my way isn't optimal. 3) Generated a series of WHITE bitmaps for most of the character set, using a fixed-width font The rest was fairly obvious. Though OpenGL's scaling flags suck donkey cock, so I had to make the bitmaps 64x64 (and maybe that's not even large enough for uber-displays), so that the scaling method used is very basic, and yet due to being DOWNscaled it doesn't look ugly.  Click here for the full 1024x768 image. monsterland fucked around with this message at 22:24 on Feb 17, 2011 |
|
#
?
Feb 17, 2011 22:11
|
|
|
Does anyone have experience working with "Simple and Fast Multimedia Layer" (http://www.sfml-dev.org/)? Is it any good? I found it while searching around for OpenGL related libraries and it seems like a more comprehensive glut/freeglut plus a bunch of other poo poo.
|
|
#
?
Feb 17, 2011 22:23
|
|
|
monsterland posted:The rest was fairly obvious. Though OpenGL's scaling flags suck donkey cock Fonts contain information designed to make sure stroke width is consistent and that edges fall on pixel boundaries. You don't get that from scaling them like a bitmap. Render fonts to bitmap at the size you intend to use them at. For new sizes, render them again. You don't need to use a fixed-width font either, just get the width of the glyphs after you dump them to a bitmap and store them somehow. They are always integers. Never scale font bitmaps unless you have a good reason to (i.e. 3D nameplates). Word wrap is something you can easily implement yourself: - Insert all text on one line - Set start point to 0 and endpoint to 1 - Scan all characters: - - Is the current character whitespace and the previous character isn't? If so, set the current position as the endpoint. - - Is the current character non-whitespace and the previous character is whitespace or breaking? If so, set the current position as the start point. - - Is the current character non-whitespace extending past the line width? If so, clip the current line to everything < endpoint, repeat the insert operation on everything >= start point - - Is the previous character a hyphen or other breaking non-whitespace? If so, set the current position as both the start point and endpoint. - - Repeat OneEightHundred fucked around with this message at 01:15 on Feb 18, 2011 |
|
#
?
Feb 18, 2011 00:14
|
|
|
OneEightHundred posted:Rendering a font as a bitmap and then scaling the bitmap to 75% of the original is not the same as rendering the font at 75% of the original size, ever. That is all good and well, except: * Games with with ROGUElike visuals kind of DEPEND on fixed-width fonts * My end-result looks pretty good (as you can see) * ... because I rendered fonts in 16x12 and then smoothly pre-upscaled them to 64x48, which allows me to realtime-downscale them gracefully, for that old-school DOS CRT look * My game, like VVVVVV, auto-scales to your desktop resolution. This too, would create a problem with generating "exact size" fonts I appreciate the algorithmic breakdown but Microsoft already has a function that can calculate text wrapping for me. In a game with a DOS-ish look, however, I just use fixed-width fonts for convenience and the air of nostalgia. monsterland fucked around with this message at 01:26 on Feb 18, 2011 |
|
#
?
Feb 18, 2011 01:22
|
|
|
Optimus Prime Ribs posted:Does anyone have experience working with "Simple and Fast Multimedia Layer" (http://www.sfml-dev.org/)? Is it any good? I've heard so. People in this thread have recommended it. I'm a lazy rear end and haven't actually programmed anything in ages, so I'll have to try that soon.
|
|
#
?
Feb 18, 2011 08:05
|
|
|
monsterland posted:The rest was fairly obvious. Though OpenGL's scaling flags suck donkey cock, so I had to make the bitmaps 64x64 (and maybe that's not even large enough for uber-displays), so that the scaling method used is very basic, and yet due to being DOWNscaled it doesn't look ugly.
|
|
#
?
Feb 18, 2011 08:17
|
|
|
I see monsterland and OneEightHundred have experience in this. What sucks about this all though is how it appears those are the kind of hoops one has to jump through to work with text, unless one wants to drag in a whole other engine that has a heavyweight library for doing this kind of stuff. What annoys me is that we are here in 2011 and working with text is still such a huge chore in OpenGL. All those solutions shouldn't have to be necessary.
|
|
#
?
Feb 18, 2011 08:19
|
|
|
Rocko Bonaparte posted:I see monsterland and OneEightHundred have experience in this. What sucks about this all though is how it appears those are the kind of hoops one has to jump through to work with text, unless one wants to drag in a whole other engine that has a heavyweight library for doing this kind of stuff. What annoys me is that we are here in 2011 and working with text is still such a huge chore in OpenGL. All those solutions shouldn't have to be necessary.
|
|
#
?
Feb 18, 2011 08:43
|
|
|
OneEightHundred posted:What heavyweight library? Use FreeType. You don't need to use some bullshit with an OpenGL integration layer, just render glyphs to bitmaps, store them in a texture, and keep track of the coordinates/dimensions. FreeType's a reasonably heavyweight library. Then again, if you want to do anything with vector fonts, a heavyweight library is basically necessary, because vector fonts are loving complicated. Rocko Bonaparte posted:What annoys me is that we are here in 2011 and working with text is still such a huge chore in OpenGL. All those solutions shouldn't have to be necessary. Text layout and rendering is not, and should not, be a part of OpenGL; OpenGL is a low level interface to the graphics hardware, not a graphics engine. Virtually any engine or framework built over OpenGL will have text layout and rendering features, so maybe the issue is you're trying to work too close to the metal.
|
|
#
?
Feb 18, 2011 08:52
|
|
|
FreeType is somewhat heavyweight. Sean Barret has a public domain 1800 line TrueType font rasterizer that will probably do everything you need.
|
|
#
?
Feb 18, 2011 08:57
|
|
|
My preferred way of dealing with fonts is pretty much this way: http://bitsquid.blogspot.com/2010/04/distance-field-based-rendering-of.html No external libraries and scaling of fonts looks decent.
|
|
#
?
Feb 18, 2011 10:33
|
|
|
Paniolo posted:FreeType's a reasonably heavyweight library. FT_Init_FreeType to start up FT_New_Face to load a font file FT_Get_Char_Index to convert a unicode char into a glyph index FT_Load_Glyph to load a glyph index into the current glyph slot FT_Set_Char_Size to set character size (char_height = point size * 64, leave everything else as zero) FT_Render_Glyph to render it Access the bitmap through face->glyph->bitmap, use face->glyph->metrics to figure out where to draw it. Use that to build a texture and a lookup table. http://www.freetype.org/freetype2/docs/tutorial/step1.html http://www.freetype.org/freetype2/docs/tutorial/step2.html
|
|
#
?
Feb 18, 2011 16:48
|
|
|
I have some code that loads TrueType fonts using FreeType2 and makes them into a bitmap font thing I can render easily with OpenGL. It also uses sfml2 for window management if anybody needs an example of that. Let me package it a little better and I'll throw it on github in a bit. edit: Scaevolus posted:FreeType is somewhat heavyweight. Nevermind this dude's code is probably a lot more suited to your purpose
|
|
#
?
Feb 18, 2011 16:58
|
|
|
I'm running into some problems interacting with the list of game world entities, similar to the issues HappyHippo was having a few pages ago with cities/teams/units. It's an RTS-like game, and currently all of the units on both teams are stored in one Dictionary (this is in C#/XNA). This makes sense because there are a few places where the whole list needs to be iterated over. But sometimes I will need to see if a team has a certain type of building, or how many units of a certain type it has, etc. One way, of course, is to iterate over the whole list. Is this fast enough using a Dictionary (or another C# data structure if there is a significant speed difference) of <200 entities? It might need to happen, say, 50 times during an update (as of now that's a big overestimation, but just in case). Does the size of an entity affect how fast this is? Another thing someone suggested is parallel data structures, which I take to mean having Entities, Team1Entities, Team1Buildings, Team1Units, etc. That would cut down on the iteration time, but would the small lists contain full copies of the entities or references to the master? Would some kind of tree structure where the entities are all leaf nodes and any interior node returns all leaves below it work? I'm sure that's been done but I don't know what it's called. I'm having some difficulty wrapping my head around how to implement it but I think I could do it if it would help, and it seems kind of nifty.
|
|
#
?
Feb 19, 2011 01:46
|
|
|
What about just adding a static int to each class that gets incremented in the constructor and decremented in the destructor? If you have multiple teams you could have a static int array that holds the number of units for team 0, team 1, etc. Really, I'd just try it out with whatever strikes you as simplest/easiest first. For a modern computer a list of 200 entries is peanuts to iterate through, so go with the simple option and go back and fix it if you run into a performance hit. Just hide how you count units behind some kind of Unit.Count() call and then if you do have issues later on you just have to tweak that one part of your program.
|
|
#
?
Feb 19, 2011 04:57
|
|
|
One possibility would be to make your single list of things something that resembles C++'s std::set or std::multiset, and have the less-than operator of your objects compare their type (plus some other index when type is equal, if you don't go with multiset). This way you still have the advantages of a single list, but because it's sorted you can very quickly find the desired subsets of your list. (I don't know what C#'s equivalent would be, maybe Dictionary even has this capacity already.) Disadvantage of this versus the cross-referencing by separate lists is that you can only get fast 'find' access on a single index, so you couldn't, for example, do both "everything belonging to player 1" and "everything that's a building" (though you could possibly do "everything that belongs to player 1" and "everything belongs to player 1 and is a building" if your sorting comparisons were set up right). That said, just iterating through 200 elements and skipping the ones you're not interested in is going to be pretty bloody fast and you probably shouldn't be worrying about it too much, as PDP-1 says.
|
|
#
?
Feb 19, 2011 06:16
|
|
|
PDP-1 posted:What about just adding a static int to each class that gets incremented in the constructor and decremented in the destructor? If you have multiple teams you could have a static int array that holds the number of units for team 0, team 1, etc. PDP-1 posted:Really, I'd just try it out with whatever strikes you as simplest/easiest first. For a modern computer a list of 200 entries is peanuts to iterate through, so go with the simple option and go back and fix it if you run into a performance hit.
|
|
#
?
Feb 19, 2011 06:40
|
|
|
As opposed to Glut/Freeglut I would try GLFW. It's lightweight like glut but much better. I love it, it doesn't do one or two things that I wish it would but all in all it's very good. Also I wouldn't mess around with FreeType when there's libraries that do that for you, such as FTGL which I also love.
|
|
#
?
Feb 20, 2011 09:55
|
|
|
FTGL has a convenient API but it uses immediate mode so gently caress it.
|
|
#
?
Feb 20, 2011 18:44
|
|
|
Anyone got a good recommendation on a decent HLSL reference book? Don't really need a "Teach Yourself...." just more of something like a Cookbook.
|
|
#
?
Feb 21, 2011 17:48
|
|
|
Vino posted:Also I wouldn't mess around with FreeType when there's libraries that do that for you, such as FTGL which I also love. It's all intro-level stuff, literally everything else you could want any useful 3D application to do is harder than it.
|
|
#
?
Feb 21, 2011 23:38
|
|
|
I'm sure it'd have been easy to figure out if I tried but I didn't have to write any of that code myself, so it saved me some programming time. Less programming time means more game design time. As for OpenGL immediate mode,  That's actually good news for me since I need to support netbooks and old hardware.
|
|
#
?
Feb 22, 2011 00:00
|
|
|
I have to say, I've been like OneEightHundred says for a long time and am only just barely starting to come around to "I should use a goddamn library sometimes" thinking, but now I wish I had decided to do so earlier. If you're not doing anything speed-critical then you might as well use a library even if it uses suboptimal methods, and if you are doing something speed-critical then, meh, provided the library itself isn't hard to set up you might as well use a library anyway and then switch it out for your own code later if you need the performance/flexibility improvement. Just try to make sure you use a library whose interface isn't incompatible with doing things properly later, then if the library turns out to be not good enough you can just construct the functionality you need (which you would have had to do anyway) without having to change any of your existing code that uses it.
|
|
#
?
Feb 22, 2011 00:54
|
|
|
I'm not against using existing libraries, but nearly anything that interfaces directly with a drawing API is a bad idea unless it's the ONLY thing doing so. It used to be the case that you could mostly get away with just flipping state around and then throwing poo poo at it in immediate mode, but now with immediate mode being heavily deprecated, plus all the buffer and shader management bullshittery, doing anything in a sane way basically means the only thing that will be talking to the drawing API is your scene manager or AT LEAST a geometry batcher. If you have either of those and it isn't completely brain-damaged, then drawing 2D UI components should be trivial. If you have that much, then making 2D UI components out of font information you dumped from FreeType should be trivial as well.
|
|
#
?
Feb 22, 2011 01:13
|
|
|
Sure, and actually since this thread has basically provided the code for both texture-atlasing and font rendering junk in the last couple of pages, it'd probably actually be just as easy to use that provided code/pseudocode as to use a library. But if the thread hadn't recently provided the code, using a less-optimal library as a placeholder so you can get onto coding the fun stuff would be a reasonable approach too. If you were to spend a year setting up all your texture-atlasing and font-rendering and model-loading and shader-using and etc. etc. crap there's a good chance you'd find half of it's outdated by the time you've finished, like FTGL or my old engine code is now. So it makes more sense to do your "this specific game" code first, using crappy libraries if that's all there is pre-existing, then substitute in decent up-to-date engine code once the game is working. (If you put a wrapper around the library you're using you could even fairly easily switch to another library [if there is one] rather than write your own, when the time comes.)
|
|
#
?
Feb 22, 2011 02:27
|
|
|
|
| # ? May 11, 2024 12:03 |
|
|
I don't understand why anyone has decided that FreeType is somehow complicated or "heavyweight." Are you worried about the extra size in your final binary? Are you worried that it's complicated to use? This quote is hardly exaggerating how easy it is to setup and use:OneEightHundred posted:Heavyweight as in what? Large? Because it's certainly not difficult to use. It is pretty much that simple. FreeType is a really good, small, well-tested way of getting fonts rendered to a texture in memory. What's simpler or lighter than that? In any case, it's kind of a silly thing to argue about. If you can find some code that does it more simply and the scaling method you're using looks fine for your purposes, then go with it. Use FreeType if you want fonts that behave like fonts. speng31b fucked around with this message at 05:00 on Feb 22, 2011 |
|
#
?
Feb 22, 2011 04:54
|
|
