Jump to content

  • Log In with Google      Sign In   
  • Create Account

slicksk8te

Member Since 25 Sep 2012
Offline Last Active Mar 17 2016 01:29 AM

Posts I've Made

In Topic: Modern OpenGL Transforms, HOW?

11 January 2016 - 11:28 PM

Thanks for the help. I have tried instancing and it does mostly work for what I'm doing.

Don't UBOs have a relatively low limit for max size?

I'm guess I'm still unsure how AAA games are able to have so many meshes rendered along with things like particle effects

What strategies are employed to reduce the number of draw calls and be able to maintain independent object transformation?

I'm sure instancing is used for particle effects but I'm not sure how this is done in practice because there can be many emitters that (i.e. many explosions) die after some time. Would the buffer that contains the transformations have to be scraped and refreshed every time a particle died?

I'm pretty good at getting an implementation together once I understand the strategies but I'm having trouble finding best practices on this stuff. There are many beginner tutorials our there but I can't seem to get information on how AAA does these things in practice.

In Topic: Python Keyword Arguments for Config files?

07 August 2015 - 08:20 PM

What type of use case are you looking for? There are many ways to handle configuration in python and each offers very different pros and cons but typically are good for specific uses.

 

Keyword arguments can be useful but I try to avoid **kwargs style syntax because it can make it difficult to understand what types of arguments the function can take.

 

I like to usually use properties + builders to accomplish configuration like the following:

#useful for config files?

#If the following variable is false, no camera will exist?
camsOn=True


class Camera(object):
    def __init__(self, **settings):
        self._settings = settings

    @property
    def all_settings(self):
        """Be able to get all settings and present them as a dictionary but is read only."""
        return dict(self._settings)

    @property
    def mode(self):
        return self._settings.get('mode')

    @property
    def radius(self):
        return self._settings.get('radius')

    @property
    def focus(self):
        return self._settings.get('focus')

    @property
    def angle(self):
        return self._settings.get('angle')

    @angle.setter
    def angle(self, value):
        """An example of a setter but by default properties will be read only."""
        self._settings['angle'] = value

    @property
    def frustrum(self):
        # This is a function so you can add any additional logic here.
        return self._settings.get('frustrum')


def camera(**settings):
    if camsOn:
        return Camera(**settings)

    # Also could raise here if no camera is an error or the user should know about it.
    return None


cam1 = camera(mode='PERS',radius=0,focus=(0,0,0),angle=(0,0,0),frustrum=0)
cam2 = camera(mode='ORTHO')
# the power of a function is that logic can be added

 
cam1.angle = (23,68,79)
print cam1.angle


# FUNCTIONS
def get_settings(cam):
    global camsOn
    if camsOn:
        for settings in cam.all_settings:
            print str(settings) + ' = ' + str(cam[settings])
    else:
        print 'Can\'t get settings'
        return {}


get_settings(cam1)
print
get_settings(cam2)

I know classes seem overkill but they allow you to be extremely explicit and have defaults automatically specified as well as easy usage because there is no need to care if a particular setting exists or not. Also, properties allow "read only" values if you do not have a setter. And finally you can change the source of the configuration any time without changing any of the usage code because you have abstracted it out. For instance you could read this information from a file in the builder and pass it into the object and you would use it the same as if you just used a flat dictionary.

 

It all depends on your use case but in the method above you could have logic specific to the settings either in the property functions or the setter or the builder that creates the settings object.


In Topic: New to programming!

21 July 2015 - 04:37 PM

Not sure if this is being monitored or not but I believe the op's question  was where to start with programming in general and then how to transition into game development.

 

You can pick virtually any programming language to start from but with the big caveat that some languages are harder than others to learn and for example C can have a pretty steep learning curve for more complicated programs.

 

I started in C and I believe it is a valid starting point but it is like starting in the deep end. If I was starting to program for the first time today, I would choose python. Of course this is a personal opinion and I believe that there are a lot of really complicated concepts that need to be learned when starting with lower level languages. Python however is more of a top down approach to programming rather than a bottom up. 

 

I believe that the best way to learn to program and game programming is to just try things out. Higher level languages like Python allow this because it is really easy to get started and there is a lot of details that you do not need to worry about.

 

You really just need to learn a programming language and write programs to get used to the thought process and how to think about problems. Once you learn one programming language it becomes easier to learn more.

 

Hope that helps


In Topic: Text Based game Types

17 February 2015 - 11:40 PM

Ohh totally forgot about dwarf fortress! That actually brings up an interesting thought of what constitutes a text based game. Is it the input method or the presentation layer? Or maybe some other criteria.
But some good input so far. I didn't even think of the sim route.

In Topic: Text Based game Types

17 February 2015 - 04:22 PM

Did you display a map?

I can see how a turn based game you could use commands like "invade saturn with 10 armies"


PARTNERS