Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2011
Offline Last Active Yesterday, 11:38 PM

Posts I've Made

In Topic: glew does not initializes extensions

06 April 2016 - 12:35 AM



Have you initialized GLEW (called glewInit()) after creating an OpenGL context?




I mean, if it works when you initialize it in the DLL, then maybe it's because you initialize the DLL after you've created the window and an OpenGL context.

And perhaps it doesn't work when you initialize it in the EXE, because you're initializing GLEW before you've created an OpenGL context (and the window, maybe).

In Topic: Creating multiple viewports in SDL/OpenGL project, how to implement?

23 February 2016 - 07:08 AM

You don't need any additional OpenGL contexts for multiple viewports.


You only need to call glViewport() to change which part of the screen to render, and then render as usual. You'd, of course, do this for each viewport.


If I'm understanding you question correctly, you want to overlay an HUD and minimap (etc...) over your 3D scene (much like any FPS, for example).

To do this, you don't need to change viewports at all.

You just need to render your 2D HUD (and minimap) after you render the 3D scene.


Changing viewports is used for things like, a 3D model editor (Blender, 3DS Max, etc) that has several views for the scene your editing, like this:



If you want to check out a tutorial for multiple viewports, you can go to to NeHe's.

It does use deprecated OpenGL, but the viewports part is still used i modern OpenGL.


EDIT: WhoopASword beat me to it rolleyes.gif

In Topic: Beginner asking for advice

05 February 2016 - 02:31 PM

Ok, to somewhat simplify the question of whether to use a tool (GMS, Contruct, Unity, etc) or a standard language + some API (think something like C++ and DirectX), one could say tools trade freedom (as in features available, and things like that) for simplicity of use.


You don't need to use C++ or C# and OpenGL/DirectX to be a "real" developer.

It is irrelevant what tool/language/API you use, as long as it works for you.


The main advantage of those tools, is that you focus mainly on the game creation part, instead of having to write code for every little thing your game does (like you would, if you use C++, for example).

The trade here is that the tool constraints what you can do (compared to, again, a language+API), but in turn allows to create stuff much faster and easier.


Oh, and what i meant for game design/architecture, is the game itself is composed (things like objects, how to do collision detection, impementing enemy AI, how to move your characters), and not code architecture.

Basically, this game developing knowledge will stay with you, even if you move to another language, because, although, you'd obviously have to learn the language and how to implement these things in that language, you'd already know how the game elements work together and how to make the game working.

This is knowledge that remains relevant regardless of whatever language or platform you use (like Looniper said, similar to cross-platform development).


There's one thing you could think about among those tools, and that is the basic language they use.

I mean, Unity uses C#, Flash uses AS3, Contruct 2 HTML5, so you could choose one that you think would be more useful in the future, although i must reiterate myself, and say that this is secondary to the experience you'll gain in the game design.


As a side note, although i mentioned Multimedia Fusion earlier, this is one i'd recommend not using, considering the alternatives.

This advice comes not from experience, but from the developer of the infamous I Wanna Be The Guy, who says he regrets using it.


As for Flash, from the tools mentioned, it's the only one i've used, and it's pretty awesome.

ActionScript3 is similar, in sintax, to C++/Java, which made it easier for me to get into, because i was already familiar with C++.

I can't say whether it is easy or hard to learn, but i think it wouldn't be much different from the other tools.

Another good point though, is that, pretty much like GameMaker, Flash has been around for a long time, so there are a lot of tutorials for it. Just make sure to search for ActionScript 3 tutorials, if you choose to use Flash, because AS2 is deprecated.


As a last note (and the fact that it is a SHMUP is a coincidence) here's a great game made in GameMaker, that i happen to discover recently.

It's like mix of Konami's Gradius and Irem's R-Type. You can find it here.

I just mention it here, so you can have an idea of what can be done with GameMaker.


Well, that's about it. I hope this is more comprehensive. smile.png

In Topic: Beginner asking for advice

04 February 2016 - 10:14 PM

Well, to start of, there are platform games written in GameMaker, so given that they (the characters) require free movement (pixel by pixel), then i'm positive the movement you want would work too.

One that does uses only tile-by-tile movement is RPG Maker.


Do note that I'm not trying to sell you the idea of using GameMaker of Multimedia Fusion by any means.

In fact, i have not used either of them before, altough i am familiar with what they can achieve, and given that there are a lot of tutorials on how to use them, perhaps they would be easier for a beginner to get into.

I have used Flash before, and i have to say you can make any kind of 2D game with it, and it is pretty popular. Just check any flash games website to see what it is capable of.


About the SHMUP idea, i don't mean you have to make a carbon copy of Space Invaders, or the sort, especially if it doesn't interest you.

The thing is, altough the games are quite different, the principles are similar, it's just that a simple SHMUP is a self contained thing (think, single screen game, no overly complicated map/obstacles, etc). And these simple SHMUPS happen to be pretty popular in beginners tutorials.


A bit of a side thought here, but, i think that the biggest draw you'll get from this project, is the game design/architecture part, and not the actual tool/engine nuances themselves (unless you plan on using the same tool in the future).

I think this is especially true, if you them intend to learn an actual language later, like C++, C#, etc (as opposed to AS3, or whatever scripting language the tool uses) to use with more advances engines/APIs (like OpenGL, SDL, DirectX), because, although the language may be different, you'll already be familiar with how to structure your game and how it works.

So it's not like if you use GameMaker (or some other more simple tool) you'll be wasting time since it doesn't scale well with more advanced projects, because you'll still gain the experience of game design/structure.


So, once again, as long as the tool is capable of doing what you want, just go with the one that feels more comfortable, or looks/is more simple.


I hope this doesn't come out too confusing, and if it is, i'll be happy to (attempt) explain further.

In Topic: Beginner asking for advice

04 February 2016 - 07:26 PM

Hello there, and welcome to the forums.


Perhaps, since it's your first project, and you're looking for a simple tool, you should consider something like Game Maker of Multimedia Fusion?

These are pretty limited (compared, of course, to Unity and such), but they are also easier to get into, and i think would suffice for a (relatively) simple project, although Construct seems user friendly enough (don't quote me though, i've never used it, just checked their website).


The good thing about something like Game Maker, is that it has been around for a long time, so there are plenty of tutorials to go with it.


You could also try you hand at Flash (using Action Script 3), which also has many tutorials. There's lots of great games written with it.


As a side note, since this IS your first project, may i suggest you try something simpler, like a Shoot 'Em Up (something simple, like a Space invaders clone)?

I only say this, because a zelda-like game is quite a bit more involved than a simple SHMUP, and you'd get a feel for moving sprites (your ship), basic AI (the enemies), collision detection (bullets against enemies/you), etc.


Either way, you can just try each for a bit, and then choose the one you like the most, since i'm pretty sure they all allow you to do what you intend to do.


Hope it helps.