# XeonXT

Member

88

209 Neutral

• Rank
Member
1. ## English 111 research paper on procedural generation?

Wanted to add my 2 cents on this one, since I'm also interested in PCG. I disagree completely with the statement that it should be saved for a higher-level or more math-related course. In fact, I think you could have a wildly fun time writing about this, and probably learn some great stuff in the process. I recently wrote a final research paper and gave a presentation on the topic in an English/Speech class. It couldn't have gone better. You don't even need to mention math to get the idea across. Procedural generation is such a cool concept that I think almost anyone can get excited about it without even hearing the word math The fundamental ideas behind procedural generation are easy to explain - it's a concept that is far more general than just "math," although math is certainly the most prevalent means of implementing the concept. Again, procedural generation is a concept, not a field of math! Hope you chose to go with it! As Shonumi said, would love it if you'd share when finished ;)
2. ## Resources to learn about graphics techniques

Hmm...RTR is definitely not where you want to start for learning beginner techniques. I would recommend Riemer's tutorials, they're actually a great starting place (that's where I started, and it served me well). http://www.riemers.net/ Following tutorials can get you in the hang of things, and honestly, all you need to do is absorb. There won't be any tutorial telling you exactly how to do the thing you mentioned, but once you understand vert/index buffers, alpha blending, texture animation, etc (you actually already seem to understand a good bit of how something like that might be put together), then it'll all start coming together for you. Just keep reading and reading! But start small and work up.
3. ## Keeping Ptr/Reference Differences Clean

Hello! In my game engine design, I'm trying to figure out the best way to deal with the differences between pointers and references. For example, I write many functions that take some object as a reference, and oftentimes it is convenient to pass in just a reference. But then, sometimes I have a resource that is dynamically-constructed, so I have a pointer and end up having to pass in a dereferenced pointer, which is annoying. So I often end up creating a second version of the function that takes a ptr and just does the dereferenced-pointer-call automatically. As you can imagine, it looks rather nasty to have two versions of every function that must take something by reference. So I considered a different technique: allow certain objects to automatically cast themselves to pointers to themselves. That way, the compiler would automatically do the cast when it saw that the function takes an Object* and I'm handing it just an Object. Of course, there's no doubt in my mind that this is bad practice. It just sounds like bad practice. Any advice on how to cleanly solve this problem?
4. ## Bloated Assembly!

Really, so you tried tinycrt and your exe did not shrink? Did UPX not work either? I look forward to you posting what you learned to give back to anyone else who stumbles upon this thread having the same issue. [/quote] Well, I was already familiar with UPX. And UPX is definitely an amazing compression tool, but compression isn't really the same as producing a small assembly. Since I always use UPX in the end anyway, my goal was to get it as lean and mean as possible before running it through UPX for the smallest possible final size. I'm a bit confused - I thought tinycrt would only help if you statically linked to the runtime library? Am I wrong to think that I am dynamically linking to the CRT (and thus not incurring its expense)? I'm not so clear on that part.
5. ## Bloated Assembly!

Well, thanks to all who tried to help me with this. In the end, none of the suggestions were able to get rid of the bloat, so I ended up doing my own little studies on the compiler & linker to figure out how to get rid of the bloat. To my surprise, I learned many (somewhat scary) things that I didn't know. Here are two of the most important observations I made (just in case anyone else finds this useful): 1) If a class is instantiated anywhere in code that gets included, then all of the virtual member functions (along with any virtual functions of parents) get automatically included. Ouch. 2) Member functions implemented *after* being defined (i.e. forward declared in a class) do some nasty things. Any instantiations made in such functions will cause instantiated class' virtual member functions as well as constructors and vfptr tables to be included in the assembly (even if this member function is never used). There are also some other cases where this will end up causing other, non-virtual member functions to be included in the assembly. These two facts allowed me to hunt down the culprits of most of the bloat. I may post some more information when I have conducted a more thorough analysis and wrapped my head around all the cases. Seems the compiler isn't nearly as trustworthy with size optimizations as I thought :/
6. ## Bloated Assembly!

The first response mentioned something about pointers aliasing *symbols*. Do you know what that is? I'm familiar with the basic pointer aliasing that you described, but I feel like the first responder could have been right - it does seem like pointers would be able to confuse the compiler and cause it to add extra code. Can you elaborate a bit on this?
7. ## Bloated Assembly!

I really don't think it's anything to do with the runtime library. I'm getting along fine linking to it dynamically. My real problem is with the extra junk from my *own* library that is getting included when it isn't used. Anyone have any more info on pointer aliasing/code examples of when that happens?
8. ## Bloated Assembly!

I guess this is a better way to phrase my ultimate question: What factors, other than straight-up using a function/class in the main code, can cause the code for that function or class to be included in the final output? Am I correct in understanding that if class A uses class B but neither class is ever used in the main code, then neither class will make it into the assembly? If that's the case, I don't understand what factors are causing this extraneous data...because I literally just set WinMain to {return 0;}, and I don't have any global data (as far as I am aware).
9. ## Bloated Assembly!

I really think this has something to do with aliasing, but I'm not familiar enough with it to understand. Anyone know of any resources on how/why the compiler gets confused and adds unused code? That'd be really helpful! Hmm, I really don't think that I have any global objects. I also have all of those linker/compiler options set...still lots of bloat? Well, I actually don't have RTTI or EH enabled, so that can't be the issue. Also no SSE code (yet :]), so it's not that either. I don't have any global data, but I may have static functions. If I have a static function in a class, does the full code for the class automatically get included because of the static function? The project is about understanding how to be size-efficient with an executable. I was hoping to avoid the "why-are-you-doing-this" type discussion I'd really just like to waste as little space as possible. 64k will probably be the target size. I'd also just like to conceptually understand why things get added to the executable if they aren't used (which I think is valuable knowledge ) Thanks to all. Would still like to learn more about this :]
10. ## Bloated Assembly!

Can you elaborate on these effects or provide links to somewhere that I can learn about this? I'd like to see some examples of exactly when and how this can happen. I have a feeling that pointer aliasing might be the problem...in this case, how would I fix that? Thanks for the links...I'm already familiar with UPX and it certainly helps, but it doesn't eliminate the unnecessary data altogether. I'll look into strip. My mistake. Visual Studio 2010. Would gcc do a better job do you think?
11. ## Bloated Assembly!

I'm currently not satisfied with how the compiler is optimizing my executable for size. When I look at the assembly generated, it's not nearly as small as I think it could be (just in terms of optimizing away stuff that isn't ever used). For example, if I include my own little graphics engine in a project but don't ever use any of its components, I still get a lot of assembly dealing with functions that appear in my library (~10kb of stuff that doesn't need to be there). Without going too specific (i.e. giving code examples, which would require me bundling a ridiculous amount of engine code as well), are there general tips that you guys have for how to get the compiler to generate the bare-minimum assembly? I've already got it set to optimize for size and the linker set to remove unused functions (and it's doing whole-program optimization, of course). I'm really not too clear on when the compiler is or isn't able to leave code out of the assembly, so it's completely possible that I'm doing something stupid that's causing it to have to inject extra code. Still, I'm not *using* that code, so it doesn't seem like it should have to be there. Thanks very much!
12. ## Efficiency of Blending Textures

Yeah, that's sort of what I figured. Thanks!
13. ## Efficiency of Blending Textures

When combining two textures, I'd like to know whether it's more efficient to have the shader do the combination work (as in, sample from the first texture and return the result of texture1 + texture2) or to set the first texture as a render target, then enable alpha blending, then run a shader that just writes the second texture with alpha blending. Currently I'm doing this with the first method, because for some reason alpha blending scares me in terms of speed. As far as efficiency is concerned, which of these is better (or are they the same)?
14. ## Rotate one Vector onto Another

Thanks to everyone for the informative replies. Building an axis-angle rotation matrix was just what I needed, and using a cross-product to find the axis of rotation is beautiful! I was totally unaware of this technique. Anyway, it works now :) Thanks again!
15. ## Looking for a good book on writing a 3D engine

Quote:Original post by Narf the Mouse Quote:Original post by Saruman Game Engine Architecture by Jason Gregory Why do you recommend this book and what in it did you find most useful? Seconded. It's the definitive work if you ask me (but, like m1o1d1 said, there's no replacement for hands-on experience and forum-prowling). I rented it from our library and will be purchasing it shortly...it's just a great read. You need to get the "bigger picture" of an engine before you start designing, otherwise you'll end up with lots of disconnected components that just don't mesh. By priming yourself with this book, you'll have a lot more direction in designing your engine, and will have enough knowledge to be confident that you aren't just crafting an ugly, fragmented library of engine components. At the same time, Gregory covers a lot of in-depth, nitty-gritty stuff. I found the chapter on memory management to be particularly inspiring. Of course, the "Game Programming Gems" series is a must-have. I haven't checked out the "Game Engine Gems" series yet, but that certainly sounds promising.