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!


Satharis

Member Since 18 Oct 2007
Offline Last Active Yesterday, 09:44 PM

Posts I've Made

In Topic: C Language and SDL - Getting Ready for Vulkan API

18 June 2015 - 01:24 AM

if you're never done graphics programming, Vulkan is not the API for you. Khronos and Microsoft are recommending that simple projects or novice programmers stick to OpenGL/D3D11 rather than trying to jump to Vulkan/D3D12.

 
Where did you get this from? Link?
 
While Vulkan like DX12 or Metal will require more code, I don't think this makes it more complicated. In fact I rather expect Valve to ship examples with MIT licenced code. So I guess around August/September you could start programming for Vulkan. I'm curious if X-Plane etc. will make that move.
SDL is cross platform but I've only used 1.2 for texture and sound loading. OSX install was a bit annoying. Lots of wrong osx examples floating around...

I'm assuming there are two reasons for implying people shouldn't change.

1. Completely revamped architecture: this one should be obvious, particularly for people that may not have much experience with graphics a lot of the changes to how things work in relationship to the actual work being performed on the cards may be confusing. Also a big one would be a lack of material available, you'll be stuck with pretty much whatever documentation you get with it.

2. The whole design they put forward with on Vulkan is that they're removing the waste and the safety limits on the code, the new style is supposed to be similar to C++ in nature, allows you to shoot yourself in the foot very easily if you don't know what you're doing, and you may not even realize you're doing it.

I don't think people will listen to such advice though, and honestly I can't really blame them. Someone out there has to try out the new thing and screw up till they start to understand it. If anything the advice is that you'd be much more productive with the tried and tested API's.

In Topic: C Language and SDL - Getting Ready for Vulkan API

18 June 2015 - 12:23 AM

People actually write games in C?

In Topic: Engine design, global interfaces

10 June 2015 - 02:31 AM

What the singleton debate really comes down to is not singletons, it is global state. I would say most code theorists or people that want to figure out better practices seem to come to the conclusion that global state causes more trouble than it solves and keeping code compartmentalized has many benefits, including simpler code reuse.

If I had one big complaint about these forums that might make sense to point out in a thread like this, its that a lot of people tend to get way too passionate about the designs they have run into over the years, they get through many failures and find what are probably good design patterns, but then they stop searching. They don't keep looking for even better ones they just come here and preach thme as "this is THE WAY it must be done."

If there was a "this is the way it must be done" we'd probably all be sitting outside on rock chairs looking at a sundial to tell the time of day.

In Topic: Special question about learning (STL and STD, etc.)

10 June 2015 - 12:09 AM

If you are learning I would try to do a 'real' project of some kind.

Yes.
 

Even something simple like a console program to calculate pi to a million places or something.

Er.. maybe. The entire point of making things to learn is to progressively set yourself bigger and bigger challenges. I could use a racing game as an example.

You might start racing on a simple circular track, you've never driven the car before and the controls, weight of the car and movement are foreign to you, you start in this simple track to learn these things, but after awhile you aren't going to get much better at handling your car just by driving that simple track. Moving on to more complex things a step at a time is the best way to get better at anything, coding included.

Using another racing analogy, books can help, you can learn about how the car works and read up on techniques to improve your driving, even watch other people play the game and such. But as anyone who has played a game after watching it will know, there is always a big difference between experience and study. You can watch ten different people drive one particular car on one particular track until you can recite every inch of it in your sleep, but you still won't learn the minute details of experience and feeling that come with doing it yourself.

A bit of a rant but I feel this part in particular requires a lot of emphasis, you can read an advanced graphics coding book front to back and unless you actually go and make things none of it is going to stick.
 

I don't think there is much point to learn STL. It's crap for game programming,

I don't know where you got that idea, I use standard library classes all the time, they're much more performant than what you or anyone you know is likely to write in any reasonable amount of time.
 

and if you get a job working for a company doing C++ they will probably have their own data structures.

They might, most of the time if thats the case it is because the environment(engine or whatever) came with that stuff already implemented to be a more performance intensive version for games.
The main weakness for stl classes in games is that they are very generic whereas games benefit much more from more specialized containers and algorithms.
 

It's also fairly complex and using it won't really teach you much as far as what's going on.

So you should avoid using helpful code because you don't understand how it works? I would postulate the opposite, that you should take advantage of useful and convenient code whenever you can and learn more about it when it strikes your fancy or when the knowledge will be useful to you. Using stl classes made me look up and learn a bit about a lot of things I had never used before.
 

You need to learn at a low level before you worry about high level APIs too much, basically.

You talk about jobs and such but at any job, especially as the new guy, you're not going to be making that low level stuff. They're just going to toss you into some corner of the code, lay out your clay cutting tools before you and say "make stars explode from this carrot" using more or less existing code. Yes knowing that low level stuff is helpful, in fact it makes you a much better programmer in the long run. But you shouldn't act like someone has to stop and learn how everything in the programming world works before they start writing any code. Oh and i'm not trying to downplay jobs, but in reality when you're new people don't know what they can trust you with, so they treat you like they would their potentially dumbest employee.

As a footnote, if you start writing a game and think about including that nice vector class and go "I bet I can write that better" you're already failing at game programming, quite honestly. What seperates good programmers from mediocre ones are being able to accept the fact that their skill will be required -when it is required- and you should try to avoid having to use it if possible. Don't rewrite a class just to rewrite a class, your mantra should be not to rewrite an stl class unless you have great need and benefit from doing so.

In Topic: Why don't game engines run in kernel mode?

06 June 2015 - 08:10 PM

This is kinda like saying cars are too slow, so rather than further develop the cars to reduce waste and improve their performance we just strap rockets to them.

Except in this case even if that didn't already sound like a bad idea, the rockets would barely carry the car's weight and have a high chance of exploding on ignition.

PARTNERS