Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Jun 2010
Offline Last Active Yesterday, 06:13 PM

#5243448 Is it worth to use index buffers?

Posted by Juliean on 29 July 2015 - 05:01 PM

See https://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawArrays.xml for example. It says the index type needs to be unsigned byte or unsigned short - it doesn't look like the indices parameter is optional. And actually the documentation for draw elements that you linked states the number of indices to draw, not vertices..


Uh, did you post the wrong link or did you mix something up? What you mean is glDrawElements, which, yes, needs indices. glDrawArrays like you (and MJP) have posted is the non-indexed rendering variant. If you look at the documentation you will see that dlDrawArrays doesn't have the "index type" parameter you describe, its in glDrawElements ;)

#5243372 Is it worth to use index buffers?

Posted by Juliean on 29 July 2015 - 08:29 AM

Is there any performance advantage in using index buffers?


Yes, in some cases.


The first important thing to remember in most common cases is: Memory consumption reduction = performance improvement. This is due to the increasing gap between memory and processor speed, with processors getting faster at a rate much higher than memory (certainly true for CPUs and GPUs are likely not different).


Even outside from that, if you can eliminate "duplicate" shared vertices with an index buffer, the post-transform cache is more likely to being able to reuse the same vertices, which means that you can save many vertex shader executions/vertex processing. This goes along with common optimization techniques to make use of the post-transform cache, you might want to look into that.


There are exceptions, of course, you will not just have net gain by using index buffer. A 3D cube with lighting won't gain anything from an indexbuffer, since though the corner vertices share the same position they have different normals per side. But I belive that for general models, index buffers are almost always the right choice (you might want to use 16 bit indices if possible to save even more memory/performance).

#5242971 Resolution scaling and World / Screen Coords

Posted by Juliean on 27 July 2015 - 08:19 AM

What is the best / proper way to consider the bigger (or smaller) resolution? How should I be doing this?


If you are OK with a blurry scaled image, you can just set the backbuffer resolution of your application to 640x480, which will fit it to the screen automatically (you don't show your usesers any resolution settings when the logical resolution is fixed anyways). Alternatively, you can always just render your scene to an offscreen texture, and copy it to the backbuffer in a final pass. The main advantage of having the backbuffer in the logical resolution of your game is that screenshots & screen recordings will already have the correct size.


I'd also give the option of eigther a windowed mode where your window size is equal to the logical resolution of the game, and alternatively also a mode for fullscreen where you render the game in real resolution in the center of the screen with nothing around it.

#5242954 Design pattern for linking UI events to editor code?

Posted by Juliean on 27 July 2015 - 06:55 AM

But then wouldn't you end up with a large amount of command classes?


Depends. Generally yes, but you are not going to avoid that alltogether. Its way better to have a lot of classes then a giant if statements because 1) the classes are independant of each other and thus 2) all the classes can be organized and managed better. You still have to realize that if you have different parameters that you want to couple to your UI, you will at least have to write SOME code for letting your application know that this parameter exists and what to do with it.


But if you want to reduce the amount of code for parameters, here is what you can do. Instead of writing a different class for each parameter, you use a template class (for the type) and store a function pointer:

template<typename Type, typename Object>
class ParameterCommand : public ICommand
	using FunctionPointer = void ()(Type);
	ParameterCommand(Type value, Object& targetObject, FunctionPointer targetFunction),
		pTargetObject(&targetObject), targetFunction(targetFunction)
	Type value;
	TargetObject* pTargetObject;

	FunctionPointer targetFunction;

And then you can just do:

ParameterCommand<float, Brush> radiusCommand(5.0, brush, &Brush::SetRadius);

This is just an example and might not even perfectly fit your use-case, but you get the idea. Command pattern, unlike your nested if-list, allows you to use all the class/template magic of C++ to reduce the amount of things you have to write. But you have to write some code for each parameter... wait, you are using C++, right? There might be even easier tools in other languages based on reflection, but command pattern is still a viable top-level solution which allows you to solve the specific subsets of your problem the way that your language makes it the easiest.


On an unrelated note, was the brush-example an artifical example or do you really plan on making those undoable too? I'd advice against it, I hate nothing more than wanting to undo a series of changes I made, and having the application undo all my brush/tool changes in the mix. Might be personal opinion but not many applications even do that which I've seen.

#5242856 Organizing rendering code

Posted by Juliean on 26 July 2015 - 04:35 PM

That's pretty much what the pImpl Idiom does... it works, but using a pattern not in its 'pure' form can be a philosofical dilemma to some...


You appear to be way too focused on patterns. Don't do that - don't just apply a pattern because its a pattern. Use the solution that fits the case best - most patterns are just names for common programming solutions with potentially different variations, but if you insist on doing things exactly like some pattern just because someone showed it that way, you are in for a world of hurt ;)


On part of your actual problem, there is nothing wrong with adding code to your  RenderManagers method which uses impl. There is even kind of a pattern for it, called NVI, just that you are using a pimpl (or a typedefed class in case of AThompsons solution, which I'd recommend you take).

#5242827 Who wants to see a C replacement?

Posted by Juliean on 26 July 2015 - 02:56 PM



As a one man show who does not need to manage all of this on a constant basis, I can see headers being alright. I personally have to manage headers on a daily basis. I am not sure if this is anything like your situation.


Yeah, I definately don't have much experience in that field of yours. I was also trying not to state it as factual, but just what I personally see in my own work/experience smile.png


I still wonder though, maybe because again I don't have much expertise in what you are doing - but is this really being adressable to the seperation of header/source? I mean, you need to have the correct header for the libary to compile anyways, don't you? Which makes me a bit confused about whats the difference between if you have separated headers/source here, because in any way you would need to distribute 1) source files and 2) the binaries, right? Even if you where to have everything in a single source file instead of split declaration/definition (which you can do in c/c++ anyways, it just fucks up compile times badly), you would still need to distribute the correct source file to the "end user", would you not? (Corret me if any assumption turns out wrong at any point). So from what I can see the issues lies more in the way the c++ compilation model works in that you have to "include" the source files, rather than import a module/whatever (see Java, C#...). Which means that you could potentiall still have a way of seperating header/source as a means of organisation (just going from my personal point of view), in conjunction with a Java/C#/Pythong-like source usage model, which would give the best of both worlds... again, tell me once I make a misassumption about the underlying problem.




Same question: Did you read what I stated previously? std::bind -> C++[11]? Templates , etc.. Who said I was throwing out solutions? The only solution I threw out was C++. With the current technology at our disposal, RAM / ROM budget, and C++ feature set, it does not meet our needs


Well, you should try to understand that it is throwing people a little off if you are asking on improvements to C based on your working situation, when clearly that situation is partially addressable due to (for the time) extremely limited system resources and an inability/unwillingness for change [on your companies end; I don't know the whole situation so don't take this as negative judgement]. I also find it a little confusing when you are basically giving a general-purpose wishlist of improvements for C, when you are more or less tailoring this list around very specific needs due to said limited situation in your company. The question I have here is: What is the point of applying those improvements to C, when in the general case you already have viable solution like changing to a higher-level language for most of the points? Though, I really don't mind talking about such a wishlist, just wanted to write this since you seemed a bit confused about why you were getting those specific reactions from people.




Having to maintain a single file versus 2 is clearly less typing and more efficient.


See I wouldn't really say that. Sure, you are having less work on the typing/definition creation end with only one file. But first of all, there is already addons/IDE-functions for that. Second, the little more typing for each method definition is really not that much. Unless you are writing getter/setter or one-line functions (which again you can always just write inline anyways), copy/pasting the function declaration from the header and putting Class:: between return value and function name is usually the fraction of work it takes to write (plus design) the actual method. Sure, just have a little more overhead, but thats really not that significant in my mind at least. And last point, which is at least where I am going from - for me personally its much more effective to have the seperation between header and source when it goes to maintaining the code. For me its way easier to skim through a small header with only declarations and click on a method and "Goto/Show definition" than if I had the whole source as part of the class declaration, since I have way less sh*t to scroll/skim through. Of course this is all subjective and probably depends on the coding style of the individual programmer, but for me its cool.


So if you ask me for what I wanted, I'd like to have the option to choose whether to write everything in one or two files, with a compilation model that doesn't f*ck up your compile times when you decide to do everything in the header.

#5242812 Who wants to see a C replacement?

Posted by Juliean on 26 July 2015 - 02:01 PM

Am I the only one who actually likes header files? I love having a nice small interface in one file, and then the actually code tucked away in another. When I have to use C# I always miss my header files...

Definately not, I was going to say the same thing. I actually enjoy having only the declaration of my classes in the header, which makes reading much easier for me subjectively. I even miss the separation when working with templated classes which I'm used to writing inline.

#5242797 Hierarchy of meshes and entities

Posted by Juliean on 26 July 2015 - 12:57 PM

You sure helped, but I still can't grasp the whole concept. How do I implement my own scene graph?


You need to take a step back at this point and read this excellent article from L.Spiro on scene graphs. What it boils down to is the simple question: Do you need to propagate values from parents to children, like position, transparency, etc...? If not, then you don't need a scene graph, and you certainly don't need to build one upfront. Focus on getting the basic entity/world presentation going in the first place, and only build in a scene-graph once you really need it.

#5241709 Creating file reader/level loader C++

Posted by Juliean on 21 July 2015 - 07:59 AM

How flexible do you need this? If you have a fixed case of an object class like this:

class Object
   std::string sprite;
   int x, y, z;

Then you can just read in the values directly:

std::vector<Object*> vObjects;
	Object pObject = new Object;
	myfile >> pObject->name;
	myfile >> pObject->x;
	myfile >> pObject->y;
	myfile >> pObject->z;

The >> operator will read the next value until a delim character is hit (space/newline etc...), and convert it to the proper type. So if you have a static file format where ie. there is always between 0-X sprites with the same format, then this is probably the easiest way. If you really need to store the read-out information in an intermediat array, I would just store string-per-string (>> can also store any value as string) in an std::vector<string> and convert the values on  use to their proper types. If there is any storage/performance overhead that you don't want, you can look into variant (boost::any), but there also is a certain overhead, mainly in complexity (you need to know which type the propery you are reading out is, so you most likely already have the target structure at hand and might as well just create it directly).

#5241186 Good C++ engines?

Posted by Juliean on 18 July 2015 - 04:28 AM

Every time I try to install Microsoft Visual Studio I get an install error, I don't remember the error exactly though, that's why I'm trying to find a C++ game engine with its own compiler...

A wild guess, did you for any reason uninstall internet explorer or have an outdated version on your PC? This is the one reason as far as I remember that Visual Studio won't install (outside of deep-down system corruption), since for whatever reason in current versions it needs the IE (don't ask me why).

#5240776 Limiting game updates but not framerate in old D3D game

Posted by Juliean on 16 July 2015 - 07:16 AM



See the last and second to last approach. What you need to do is basically fully decouple updating and rendering. You render each frame (D3D9_BeginFrame() and D3D9_EndFrame() as well as all rendering code in between), and only when the 16.66666 ms have passed, you update. This means that you cannot just check for "currentTime - startTime >= 16" and then update (which I assume also does the rendering). Notice also that your code makes no real sense anyway - you set "doupdate" and check it right afterwards, which means you might as well put the if(doupdate) code in the other condition, which defies the purpose.


So yeah, I doubt this is going to be extremely easy if actual DirectX draw calls right now happen inside UpdateGame(). You might leave out the last step in the link with interpolation, because this sure makes things another inch harder (though without it you might experience small noticable artifacts). Let me know if there is something more you don't understand.

#5240368 help making a maze in as3

Posted by Juliean on 14 July 2015 - 06:33 PM

What exactly are you having problems with? Word of advice, first of all nobody is going to want to do your homework for you. Second, people are glad to help, but you need to be more specific about what you need assistance with. Do you have any code so far? Do you have anything that throws an error, or crashes? Do you need tutorials on as3/programming, do you not understand the tutorial and want someone to translate it to code for you? Since you said "cant it to work" I assume you already have made progress of some kind, so if you could show that, people will have a much easier time helping you. ;)

#5240323 "Mode7" perspective projection "arch"

Posted by Juliean on 14 July 2015 - 02:33 PM

Thank you! In the meanwhile I've been able to fully reproduce the curvature effect. Turns out that the game simply performs x-scaling based on the mapped y-scanline, and not the screen one. There is still a slight difference to the original view, but this is probably due to me not having the correct constant for the scaling (will experiment some other day), and from what it looks like they have their x-center slightly offset from the middle of the screen, since with the new projection formula my scanlines are too far left on both sides of the screen, which doesn't fully make sense to me now. The new projection formula is this:

float y_modifier = 1.0f - ((scanline + projectionValue / 4) / (533.33333333f)); // why 4, I have no idea

I've also started working on getting the rotation right. It turns out the lookup texture approach is really cool, because I can now use different transformation features by changing the textures content on the CPU, which means I can easily test my old projection approach (which supported rotation). I think I'll have to find out the real angle of the SNES image, and then compare the scanline offsets between my uncurved map and the original curved one, to extract the relative offsets due to the curvature. With this, I should be able to use the old Mode7 for base transformation with rotation/horizon/... and simply apply the curvature values on top of that. Inb4 another two days of math :D


One day Real-Soon-Now™ I want to sit down and actually write up this mode7-capable SNES-like rendering library I've been noodling over for a year or two. It's not exactly rocket-science, but its a lot of little things to work out and all get to play nicely together. I Plan to also support layers, color-cycling, and other retro techniques that would have been historically employed.


Definately sounds interesting, though for my own developement I usually prefer to keep things as up-to-date as possible. Funny you mentioned, I have a few animated tiles from terranigma which use color-cycling, I didn't even know the wording, let alone that this was a even done that way. I always used seperate frames for those - I don't think it makes much sense to do otherwise, unless for an interesting hobby project where you really want to know/use some of the retro features.


I know very well that the devil mostly lies in detail. I'm usually skipping parts I don't need, like the Mode7 which would need to scale sprites according to their position, but right now, since I only have the player sprite, I'll leave it at not doing anything with the sprites. I'm also not sure about tool support, I have lots of debug information like tile passability, a grid, etc... but all those things obviously won't work with Mode7 since I can't just render the scene like normal due to sprites having to stick out. I don't really think its necessary for my purposes to make all those tools for the editor work with Mode7, but it would definately be some more detail work if you really planned on getting it right.

#5240282 "Mode7" perspective projection "arch"

Posted by Juliean on 14 July 2015 - 11:24 AM

So, after another day of nothing but looking at numbers and graphs, I finally got it (almost perfectly).


So I was correct about the y-values, and using a lookup texture with a 4th order polynomal for the upper map and another 3rd order polynomal for the lower map, my map shows precisely the same tiles on the horizontal scanlines than the original game:




Obviously, whats missing now is the x-displacement, which is mainly responsible for the feel of walking on a curved surface. And boy, that was by far the hardest part... or my math just sucks, I'd buy both.


What I ended up doing was again, measuring displacement from certain points on specific scanlines, but now on the x-axis. Like expected, the distances got greater the higher up you go. I soon started to notice a certain correlation between the y and x displacement, which lead to following formula:

displacement_factor = scanline_x / 533.33333f;
x_displacement = scanline_y * displacement_factor;

both positions are relative to the center of the screen (which is 0, 0). I don't know the meaning of the magic number 533.33333, but thats what I got from measuring the values. The only problem is, that this is the projection from the map to the scanline. IE. position 80,70 of the map maps to scanline 72,58. What I need is the other way round: If I have the scanline position 72,58, what map tile should I show? And yeah, not to give away the ending, but I spent literally half a day on this. IDK, I just didn't find a good inversion of the formula for required projection, and my brain probably started blocking out in the middle.


Now, what I ended up with after much thought is this:

float inv_displacement_factor = 1.0f - (scanline_y / 533.33333333f);
float x_read_off = (scanline_x / y_modifier);

I don't know if anyone with more maths experience would shake their head because its so clear that this is the inversion of above formula, but yeah... Anyways, unfortunatly this didn't produce quite the right results, despite producing the same numbers that I measured, it appears those numbers aren't precise. What I ended up with is another flat map, which makes sense seeing how the values produced by that formula are all linear (but heck, why did I even measure that sh*t then?!?). It appears that per scanline, there is an additional offset, which I more or less faked by adding the y-read offset (which is produced by the 4th order polynomal and thus not linear):

float inv_displacement_factor = 1.0f - ((scanline + projectionValue / 8) / (533.33333333f));

Now the results are almost right:



Unfortunately there is still a huge discrepancy specially in the upper left/right corners. You can only really see that if you lay the picture above each other, but I notice that the curvature doesn't quite feel right yet. I tried also adding the x-position into the mix, but that created a ugly horizontal scaling effect when moving, which also isn't quite right. I'll see if I find another solution. Also, there is a slit "yittering" slightly above the middle of the screen, probably due to the 4th order polynomal, I'll also have to look at this again.


However, even despite that, it still looks and feels way, way better than the old, flat map. So my next goal would be to find out if/how I can modify the view angle with this, and get rid of those pesky sampling artifacts (might make another thread about that).


So, thanks again to Ravyne and Dave Hunt for their input, it was very helpful.

EDIT: This is what it looks like side by side:



#5240150 "Mode7" perspective projection "arch"

Posted by Juliean on 13 July 2015 - 05:08 PM

Thank you very much for your input,


you did a great job on tipping me in the right direction. I already read up on Mode7 on the SNES via wikipedia, and that such an effect would most likely be created by modifying per-scanline "projection" values. However, you comment about it not using real-world projection values gave me the hint I needed.


I already started to measure the scanline-differences between both my projection and the old ones, but only got garbage. But then I realized I might look at the wrong problem - indeed, I should have tried to compare the scanline to tilemap mapping between the unprojected and the projected scene. The thing is, when comparing both projected version for key scanlines, there was already a "wrong" projection as part of my map, and so when trying to formulate any correlation between the key scanlines, I only got a garage function. But suprisingly, when looking at the unprojected map vs. SNES projection, it appears the game uses a 3rd order polynomal (at least for the y-projection part):




Points A-E are measured scanlines (x: difference to pivot on Y-axis, y: difference between unprojected and projected position). The polynomal is made up just from points A-D (I can even only use A-C, but then it gets quite coarse. This however means to me that I'm now looking at the right formula, and while I might need some more tuning (especially for how to get the x correct), I think using a pre-baked lookup texture can be a good solution, I just have to figure out how to exactly put those extracted values into use. Unfortunately geogebra won't show me the polynomal formula, which I assume is because the factors are too small, but since I'll have to cap them to a different range anyways... I'm quite happy, I might not only be able to reproduce the curve-effect 1:1, but I might also be able to replace the current Mode7 which I've been using previously (which has a quite bad quality) with a SNES quality style effect.


I'll post an update once I actually got something to show.