Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

223 Neutral

About m.r.e.

  • Rank

Personal Information

  • Interests
  1. I posted some videos on my YouTube channel about two vending machines I bought off craigslist. I'm looking into restoring/refurbishing them. Just wondered if any of you are into similar things. I also have a full size working arcade game.   [media='640x480']https:[/media]   [media='640x480']https:[/media]
  2. m.r.e.

    Directx or OpenGL

    I use OpenGL. I write my own base code for it too. I've use D3D before too. I use to use it a lot more, versions 8 and 9 mainly, but I turned to OpenGL. I write for Linux and Windows both. I remember using DirectDraw all the time, back in the day. It was fun! The simple things always seam so much funner for me. I remember DJGPP. I think I still have a copy of it somewhere... gasp... on floppy... do people even know what that is anymore?   My advice is to pick on (either/or) and stick with it for a while. At least until you get a hang of it. OpenGL will be more widely supported then DirectX, but if you want to write for Windows only DirectX would prolly be the best choice between the two.
  3. Okay... so out of all the times I've posted here about this “thing” called a resource manager, I did it. Well, I did, then un-did it, then re-did it. Still with me? I've tried to listened to everyone's great advice. Thank you all, again! I like to keep things simple, yet still allow me to easily extend or modify. I've came up with the following.   Continuing with the idea that resource(s) should be “custom” objects. Mmkay, custom here means they don't really derive from a overly-complex framework nor do they share(them selves included) with an over-complex framework. Nor are the developed along side an over-complex framework. The are, in short, developed independently. I left them alone like this in hopes that I could later extend or enhance with minimal troubles.   Now... on to loaders. They're not friends with resources or anything like that. Resources, if you want to continue calling them that, provide simple loading of data to their “would-be” counter-part via. Image::Load or Sound::Load. Following, Image::Load accepts the dimensions, pixel format and pixel data as parameters. The same goes for Sound, format, sample data, etc.. Sounds simple right(no pun intended)? The trick to all this is how I connected them.   I did it like this: BMP, TGA, WAV, etc.. are image and sounds loaded. They are all developed separately and load their data from file to hardware using the :Load()” functions provided by Image and/or Sound. These loaders are then grouped with like loaders and are accompanied with a very-simple cache system. The cache is just a std::map with a std::string as key and a pointer to the resource. This leaves each said resource developed separately, loaded separately and cache separately. This should allow me to easily extend and work with.   I provide access to the cache using a simple wrapper like ResLoadImage() for example. I also provide resource initialization and shutdown in the same manor. This completely abstracts the loading and caching from the rest of the interfaces. The only real down fall as far as I can see is to use this system uses pointers and each resource is dynamically allocated.   code // res-image.h #include "Res-Image-BMP.h" #include "Res-Image-TGA.h" extern void Image_InitCache( ) ; extern void Image_FreeCache( ) ; extern bool Image_Load( std::string path, Image** ) ; // res-image.cpp std::map<std::string, Image*> imageCache ; void Image_InitCache( ) { Image_FreeCache( ) ; } void Image_FreeCache( ) { for ( auto it = imageCache.begin( ) ; it != imageCache.end( ) ; ++it ) { if ( it->second != NULL ) { delete it->second ; it->second = NULL ; } } imageCache.clear( ) ; } bool Image_Load( std::string path, Image** image ) { Image* dummy ; auto it = imageCache.find( path ) ; if ( it != imageCache.end( ) ) { ( *image ) = it->second ; return true ; } dummy = new Image( ) ; if ( dummy == NULL ) { return false ; } std::string ext ; bool ret ; ret = false ; ext = path.substr( path.find_last_of( "." ) + 1, path.length( ) ) ; if ( ext.empty( ) == true ) { return false ; } else if ( ext == "bmp" ) { ret = BMP_LoadImage( path.c_str( ), dummy ) ; } else if ( ext == "tga" ) { ret = TGA_LoadImage( path.c_str( ), dummy ) ; } if ( ret == false ) { delete dummy ; return false ; } imageCache.insert( std::make_pair( path, dummy ) ) ; ( *image ) = dummy ; return true ; } // res.h extern void ResInit( ) ; extern void ResShutdown( ) ; extern bool ResLoadImage( std::string path, Image** image ) ; extern bool ResLoadSound( std::string path, Sound** sound ) ; // res.cpp void ResInit( ) { Image_InitCache( ) ; Sound_InitCache( ) ; } void ResShutdown( ) { Image_FreeCache( ) ; Sound_FreeCache( ) ; } bool ResLoadImage( std::string path, Image** image ) { return Image_Load( path, image ) ; }
  4. m.r.e.

    How big is your project?

    I just refactored my entire game. It works a lot nicer(smoother) now its down to 75 source files. I got rid of a few unused features. I was planning on using, but didn't. If I want them later, I'll put em' back in. Its pretty simple. I separate classes a lot. I think that is why I have so many sources and headers.
  5.   Oh... sorry, I'm just trying to be helpful. For later, I'll explain it. The state interface provides basic methods that are commonly used. Init() and Shutdown() are both used initialize private data the state may need: images, sounds, etc.. onLoad is used when the state is transitioned on-top the stack (i.e. added to the processing list). This is useful for when I need to reset a level or wave or something like that. onExit() is the counter for onLoad. When that state is removed from the stack, onExit() is called. onTick and onDraw are pretty straight forward, but I do iterate backwards over the list when drawing for correct drawing order. onStop and onResume are used to signal a state when it has lost focus. Basically, ALT+TAB away from application or another state was added(pushed) on top of it.   The state manager derived from state. I think this is best because I can make my GUI, levels, etc. derive from StateManager and while still treating it as a basic state. This allowed me to break up logic. For example, MainMenu is a state, Settings Menu is a state, Loading Level is a state, get it? LoadState() in StateManager is used when you want to clear the entire stack and only want the current state you specify on it. Its not really needed anymore because what I just explained about StateManager deriving from state. PushState and ExitState to exactly as the depict, push a state on the stack exit(pop) a state. The other methods allow access to protected "State" methods. They need to be there or you couldn't use the StateManager.   I declare a static instance of StateManager in the global function GetStateManager(). Once I call this function, I have a working StateManager. Its pretty simple. That's basically it. Nothing real special.
  6. I don't know if this would help but here is some of my code for my state manager. It works like a singleton. // state.h class State { friend class StateManager ; public : State( ) ; virtual ~State( ) ; virtual bool Init( ) ; virtual void Shutdown( ) ; protected : virtual void onLoad( ) = 0 ; virtual void onTick( float time ) = 0 ; virtual void onDraw( ) = 0 ; virtual void onStop( ) = 0 ; virtual void onResume( ) = 0 ; virtual void onExit( ) = 0 ; } ; // statemanager.h class StateManager : public State { public : StateManager( ) ; virtual ~StateManager( ) ; virtual bool Init( ) ; virtual void Shutdown( ) ; // list management void LoadState( State* state ) ; void PushState( State* state ) ; void ExitState( ) ; // echo void Tick( float time ) ; void Stop( ) ; void Resume( ) ; void Draw( ) ; protected : virtual void onLoad( ) ; virtual void onTick( float time ) ; virtual void onDraw( ) ; virtual void onStop( ) ; virtual void onResume( ) ; virtual void onExit( ) ; std::list<State*> list ; bool isActive ; } ; extern StateManager* GetStateManager( ) ; // statemanager.cpp StateManager::StateManager( ) { isActive = false ; } StateManager::~StateManager( ) { Shutdown( ) ; } bool StateManager::Init( ) { list.clear( ) ; isActive = true ; return true ; } void StateManager::Shutdown( ) { } void StateManager::LoadState( State* state ) { for ( auto it = list.rbegin( ) ; it != list.rend( ) ; ++it ) { ( *it )->onExit( ) ; } PushState( state ) ; } void StateManager::PushState( State* state ) { state->onLoad( ) ; list.push_front( state ) ; } void StateManager::ExitState( ) { if ( list.empty( ) == false ) { ( *list.begin( ) )->onExit( ) ; list.pop_front( ) ; } } void StateManager::Tick( float time ) { onTick( time ) ; } void StateManager::Stop( ) { onStop( ) ; } void StateManager::Resume( ) { onResume( ) ; } void StateManager::Draw( ) { onDraw( ) ; } void StateManager::onLoad( ) { } void StateManager::onTick( float time ) { if ( isActive == true ) { if ( list.empty( ) == false ) { ( *list.begin( ) )->onTick( time ) ; } } } void StateManager::onStop( ) { if ( list.empty( ) == false ) { ( *list.begin( ) )->onStop( ) ; isActive = false ; } } void StateManager::onResume( ) { if ( list.empty( ) == false ) { ( *list.begin( ) )->onResume( ) ; isActive = true ; } } void StateManager::onExit( ) { if ( list.empty( ) == false ) { for ( auto it = list.rbegin( ) ; it != list.rend( ) ; ++it ) { ( *it )->onExit( ) ; } list.clear( ) ; } } void StateManager::onDraw( ) { if ( list.empty( ) == false ) { for ( auto it = list.rbegin( ) ; it != list.rend( ) ; ++it ) { ( *it )->onDraw( ) ; } } } StateManager* GetStateManager( ) { static StateManager manager ; return &manager ; } EDIT: I originally posted the older version, sorry.
  7. Probably this (or containing basically the same information): http://www.gamedev.net/topic/682148-is-this-practical-for-a-resource-manager/ See haegarr's post especially.       Totally awesome that my post got referenced!
  8. m.r.e.

    How big is your project?

    Yeah, maybe you're right. I'm doing a lot for such a simple game. But I intend to reuse it in other games. To each, their own.
  9. m.r.e.

    How big is your project?

    Yeah... I don't include assets. Unless their scripts, because that's kinda of like programming. If I were to include all my current source, original game source and all the assets I think I would be sitting around 140-150 files. It seams a lot for a simple Asteroids type game. I could condense but I don't want large files I have to scroll through. Besides, it won't just always be for an asteroids game and some of the features I want require more. I write everything from scratch too. All home brew here! My current setup mainly consists of OpenGL related files. There is hardly anything that sets up sound, states and input, etc.. OpenGL is the heavyweight in my project. Oh... I also use glew currently. I wonder how big some of Blizzard's games are? Like... Diablo 1 or 2.   Maybe I should be looking into WHAT I need for a stable platform to work with. I see in the Quake and Doom source code the initialize OpenGL almost exactly the way I do. I think most of the bloat comes from special classes that handle things like VAO, VBO, IBOs and shaders. Then there is all the sound, image and model loaders. I wonder if it would be best to implement my own custom formats and a set of tools that works with them. Like image and sound conversion. Models are easy, since Blender lets you pretty much run a muck there. I might use Blender to generate my sprite sheets to. It has a UV layout, why not right? Its a lot better then looking at that ugly code that generates them.   Anyways, I think I'm being to hard on my self or judging my self on how large my project is. Like I'm doing something wrong...
  10. m.r.e.

    How big is your project?

    Some of the projects you guys listed are huge, and here I though a 100 files or so was big... geez louise! I couldn't imagine a project with over 100,000 lines of code, or event more like some of you listed. I should of asked that you give list or give some small examples on how you project is maintained. That would be equally impressive. So anyways, I guess my project isn't too bad. I just added a few new features to fix some other old ones. I just put the UI, logger, registry and script support back in. I'm at 106 files.
  11. m.r.e.

    How big is your project?

    The only time I refactor, or have been refactoring has been when I want to clean the code up or I to add features. I tend to snap things in quite a lot to get working, then come back and fix it later where it needs it. For example, I just finished writing a nice GUI. The rendering makes use of a Theme class. Each widget(component) in the GUI will use this theme class to draw it's self using theme parts: colors, images, sounds, etc. I just slapped it together to get it working. Later I wanted to change it to allow a more data-driven approach with out thinking about it, and I broke it. There were reasons why that happened, but now I have to go back and rewrite a bit of my framework. Effectively refactoring the code. Its okay though, because it needed done and it allows for better advancements. Eventually, all this code will become the "new and improved" engine my game runs on. I'll also reuse the same engine for other projects so...
  12. m.r.e.

    How big is your project?

      I've already done this looking at code I wrote 4+ years ago.     This is one thing I have been trying to get down. My project layout is pretty simple. I was thinking about separating source files. This way I wouldn't have to scroll through a giant tree/list when I'm currently working on a small selection. I wish I had a resource for that. Some guide of some sort that explains project layout and structuring like directory naming and similar things for large scale projects. Provide some good examples maybe, of common pitfalls the industry faces or perhaps some more personal examples from the author.   As my project growing, I realize I will need a better approach for structuring. Its hard to see into the feature to exactly what I will need or want. So I think focusing on whats important to me now would be best. Organizing common libraries and system/platform specific code. Now that I've been thinking about it, this doesn't need to be directory related. I can have only one source directory, but in visual studio or I can have an entire "virtual" directory structure. I'm not sure what would be best.
  13. m.r.e.

    How big is your project?

    Interesting. 800+ files is a lot. It sounds like I'm doing a good job at least. All those morning sitting in my chair drinking pots of coffee contemplating how the little peaces fit together, has lead me to lots of short files. I though they were bigger but I just checked and the TGA loaded is by the biggest at 689 lines. It still seams big to me.
  14. m.r.e.

    How big is your project?

    Just a quick question, how big is your project? Like... in files. I'm just curious, because mine currently has 80 files and its just the engine. I plan on adding minor features and smoothing things out a bit. This will probably grow to 90 files after that. Once I add the actual game-part back in, it will be over 100. Is that excessive? I try to have a source for every header for completeness. Most of my files have at least a few 100 lines of code. A fair portion of them have 1000+. What's your's like? I have to scroll miles and miles... hehe I hate scrolling ;-)
  15. m.r.e.

    Fix: Event Handling & UI

    As the title suggests, I've been working on the event handling and user interface. They are tied together so they are updates/upgraded together. This has added a lot of complexity to the project but I believe it will be worth its troubles. Originally, I had processed all the user input with the main window's event procedure using global variables. This worked pretty good as I could define the "actions" as variables. The variable, representing the action, would be either "true" or "false". This was pretty basic and old-school. So I rewrote, or wrote an entire event-engine. I narrowed my choices down between two patterns: Observer and Visitor. Eventually, I choose the observer pattern. I figured it's features in abstraction would do nicely. I made the "Event" the subject that "EventHandlers" would subscribe to. I've not added a priority system yet, so all subscribers are currently handled in a FIFO manner. While each subscriber(EventHandler) is notified about the subject(Event) via Event::Notify(). In this method, each subscriber's event handling procedure is called. The procedure can return "true" for processed or "false" for pass. It seams kind of redundant to subscribe to events, but it makes for cleaner code. I have two major events currently implemented: KeyedEvent and MouseEvent. Each define their own values and provide access to them via get/set accessory. Events are never queued. This may become a problem later, so I've been considering adding that feature when I add priorities. I rewrote the user interface(UI). The base of all operation is the Widget. The widget defines most of what a UI component would be. From Widget, I have wrote several sub-classes that I felt I would use most often and leave the ones I would not use that often, only implementing them on a "as needed" basis. So far I have: Button, CheckButton, RadioButton, Slider and TextField. The first three are grouped together. CheckButton and RadioButton both derive from Button. Slider, is just that, a sliding control. It's something you would use to display volume. It's similar to a scroll bar, but doesn't have the end buttons. All Widgets subscribe to events when enabled and render them selves with a global Theme. I felt using a global theme was a nice way of abstracting the rendering part from the components. In a way, they are all like builders, rendering custom images using themed parts provided by a global theme. They also use some of the image attributes, so if I change images they should adapt. I don't have a container Widget yet, nor have I implemented any layout scheme. I figured I would utilize the state machine I already use to act as a container for UI widgets. That only leaves a layout of some kind to manage how and where widgets would be and what might their tab-order be. [media='800x600'][/media]
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!