Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


blueshogun96

Member Since 09 Jun 2005
Offline Last Active Today, 01:20 AM

#5198182 Bullet hell projectiles as separate objects? Or as one whole particle system?

Posted by blueshogun96 on 14 December 2014 - 02:21 PM

I've written bullet yells before, but my coding style was very inefficient my first time around. Initially, I used pure C and linked lists, which was a bad idea because since the memory in a linked list is not contiguous, it results in a greater number of cache misses, which is a performance drainer.

Not sure what language you are using (assuming C++), but a growable heap should work fine. IIRC, std::vector handles this nicely. You can even reserve a specific size beforehand, and it will handle the heap sizing for you. If your bullet is a class, you can simply have a base class and subclasses inheriting from it with unique mechanics.

If this is your first time, you'll actually discover that writing bullet patterns is actually easier than it sounds. If you know trigonometry and how to make an object move in a specific direction and at a variable speed, then you've got what it takes! My ex coworker asked me about this, and I explained to him how easy it was.

I don't claim to be the best, but feel free to ask me if you need help. I love coding for this genre of games.

Shogun


#5192680 Building A Game Engine + Game

Posted by blueshogun96 on 13 November 2014 - 11:44 AM

 


When you are ready for the big boys (or girls) then learn C++ and SDL and then move on to OpenGL.

I don't know about C++

It's one of the earlier languages, and it's really hard to learn. I think I'll stick with C# or perhaps Java if I want to release on multiple platforms.

 

 

Why is C++ hard to learn?  Just asking because I had a harder time with C#, but C++ came naturally over a short period of time.  Maybe you need a good tutor :)

 

Shogun.




#5192573 Building A Game Engine + Game

Posted by blueshogun96 on 12 November 2014 - 10:22 PM

Shogun, my response to you was probably overly flippant. 

 

IMO, context is important here. Of course, I'm not saying that no-one should ever write a custom engine.

 

But I'm guessing that Tim Sweeney didn't post on gamedev.net asking for help learning to program just before writing Unreal. He had a big team and years of experience behind him.

 

If you know what you're doing, and you have specific requirements that are not met by an existing engine, then write a custom engine for all the reasons you outlined.

 

But you don't have to write an engine and using a 3rd party engine is a perfectly valid choice, unless you think that the Batman Arkham games were made by wimps? Also, Borderlands, XCOM, Dishonoured and the Mass Effect series. And that's just UE 3.

 

Finally, while some chefs might build their own kitchen, no-one ever calls them a wimp for not doing so or even not being able to. And no-one in their right mind would suggest that you need to build a kitchen before you learn to cook.

 

Building a kitchen and cooking a meal are different skills.

 

So is building an engine and creating a game. You might not be a shit hot engine programmer... no-one cares. Hell, let's be brutally honest. No-one apart from other programmers gives a rats arse about your code. It could be horrific, but if your game works and is fun, that's all that matters.

 

The titles you listed were created by professional devs with many years of experience, and could write their own engines if they wanted/needed to.  I'm not talking about that crowd, I'm talking about hobbyists and indies who swear by Unity, but are so reliant on it that they know nothing beyond it.

 

I understand what you're saying and it's not an invalid point, but one who is only a chef (knows only food preparation/service) isn't really a comparison to a carpenter who deals in construction and power tools.  Writing an engine and a game are not as vastly different as the former comparison and the skills to write it have small differences, so I still don't think this analogy is the best one to use.

 

It's not about what others care about, it's about what I *need* to get my game finished and in the hands and faces of potential customers, while convincing them that my game rocks and other games suck compared to mine.  If Unity, UE4 or Source, hell, even Ogre helps you get to that point, by all means do it.  

 

This isn't aimed at you, but I just get tired of rookie programmers who've only been programming in C# and Unity for 2 or 3 years trying to tell ME how to write my games and what engine I should use when I've had almost 12 years of experience as if I'm the stupid one.

 

Shogun.




#5192473 Building A Game Engine + Game

Posted by blueshogun96 on 12 November 2014 - 01:30 PM

 

Call me old fashioned, but only wimps have to rely on an engine

You're old-fashioned. Seriously though, no need to resort to name calling. No one insulted you, they were just disagreeing. You don't serve your arguments very well by being so judgmental of people who do it differently than you would. As for Tim Sweeney, if he came to me back in day saying he had no experience programming and he wanted to make a game engine I'd have said "what's a game engine?" because they didn't really exist back then. Tim Sweeney got where he is by being into programming a young age and working on it for years and making more and more complex games as he went on. Back then just making a text based game was impressive because that's all anyone was making. It's easy to be enthusiastic when you have little competition and expectations were low from consumers. Not to mention he had been into computers and programming for around 20 years before Unreal was released. All that being said I think the 'build a kitchen' analogy was weak. A better analogy might be growing your own ingredients to be a chef. Believe it or not there are chefs who do this! But I wouldn't call a chef who doesn't do that a 'wimp'. I think it's macho posturing to insist there's one true way to make games and those who don't do it that way aren't good enough. If the OP wants to make engines I say go for it and if they just want to use Unity go for that too and if they start one way and switch later because they realize they'd prefer the other way, I say go for that too.

 

 

Yeah, sorry about that.  I'm used to getting attacked over this, so I get defensive rather quickly.  When someone responds that way, I see it as a mockery, and it makes me angry.  Either way, I shouldn't have used the word twit.  One of these days, I should bring up that guy that insulted me up and down for writing my own engine (while failing to back up his own claims for not doing so).

 

Good perspective about Tim Sweeny.  Although I don't believe this really helped me much in my endeavours, I had a mental affinity for programming since I was 4 (Commodore 64 days), but didn't touch C++ until January 2003.  Since I couldn't just download unity, Unreal or Source, I (and the vast majority of us) learned C/C++, the required APIs, then either read up online about writing engines, or bought books on the subject.  It wasn't THAT much work, but it wasn't instantaneous either (the point you are making).

 

I also agree that the chef argument about building a kitchen isn't the best comparison.  Now that I think about it in person, it's like saying you should build your own computer components from scratch.  The vast majority of us don't have the money for that, even if we wanted to because that's beyond the skill of one person in general.

 

Lastly, I never said anyone using a middleware engine was a wimp, but those who solely rely on it and couldn't write their own (even a basic one), let alone understand the concept/benefits of writing one, are wimps.

 

 

 

Writing a little-e engine isn't hard -- writing a big-E Engine is. If your needs are simple, small, well-defined, writing your own engine is viable -- if you have a commercial interest or need major features that are missing from commercial middle-ware, writing your own Engine is viable. Otherwise, middle-ware engines are attractive -- sometimes they're expensive, but how much time and effort will you expend before you reach break-even?

 

If your needs are complex, large, evolving, then your little-e engine is going to have a very hard time keeping up. Your little-e engine is not Unreal, or Source, or Unity for that matter. They're generally well-proven, adaptable, scalable, and battle-tested -- things a little-e engine usually isn't.

 

That said, OP really does need to learn to crawl -- its hard to say where to start because we don't know what their experience level is. Often times, jumping into an Engine, even a simple one like Unity, for someone who's plain inexperienced isn't going to be as educational as starting with a basic gaming library like SDL2 or SFML -- in fact, the shear breadth of something like Unity can be frustrating and overwhelming for a green programmer just trying to make a simple idea happen because they have no idea how to start. But for someone who knows generally what they're doing with their programming language and who has fairly grand ambitions, an Engine like Unity or Source, or Unreal is probably the fastest path to success, and especially if they have commercial ambitions time-to-market is a strong argument on its own.

 

IMO, it depends on what you are actually writing (engine wise).  The majority of my custom engine I built wasn't even written by me, and it's a rather long and comprehensive list of libraries/tools.  Putting it all together didn't take very long for me, and it's steadily growing.  Last I checked, it was like 400,000 lines of code altogether.  Putting it together was the most challenging part because one poor design choice can lead to an evolution of cancer all over.

 

And as you stated, a commercial middleware engine has gone though greater testing then the average custom engine written after it ever has; which IMO is the best reason to consider a middleware engine.

 

Shogun.




#5192438 Building A Game Engine + Game

Posted by blueshogun96 on 12 November 2014 - 11:14 AM

 

Call me old fashioned, but only wimps have to rely on an engine (and tbh, I believe that many devs in this day and age with such easy access to middleware engines lack the talent/skill to do it themselves, nor are they interested in learning to do so)


Yes, everyone should reinvent the wheel.... rolleyes.gif

Honestly, when was the last time you saw someone telling a chef they should build their own kitchen?

Yeah, try telling that to the founder of Epic ("herp de derp, don't write your own engine, use the quake engine" even though his specific goal was to make games better than id Software could), or let's tell that to Bungie when they started writing Halo back in '97. Better yet, tell that to everyone else 10 years ago back when engines like the HL engine were well out of affordability for the average joe. Yeah, we were stupid for writing our own engine and taking time to learn good engine design practice, weren't we? Derp de derp!

Seriously, do you twits even THINK before you post this nonsense? Writing your own engine is NOT reinventing the wheel... that is, if you do it right. What I mean is that you don't have to write everything from scratch. Example, there are various SDKs, libraries, tools, etc. that you can easily integreate into your own engine so you don't have to spend time on the most tedious things such as physics, scripting, math, etc. My engine uses nothing but open source libraries that can be used in commercial projects, and it's fairly complex, even after a couple of months of refining it (still could use some more improvement, but it evolves with every new game I plan/write). Just wish I had more time for it. Heck, depending on the compiler, the minimum binary size ranges from 2.5 to 14mb; that's alot of content, and much of which can be excluded if necessary.

It's not rocket science, and I assumed it was common sense, but I guess my sister is right: common sense isn't so common. Sorry for ranting, but I'm sick and tired of this piss poor argument/example of why you SHOULD use a middleware engine. If you want to, great, if not, come at me with something of more substance than that hunk of BS because I've stomped it every god dang time!

Shogun.

EDIT: I was in a rush when writing this (job interview), and I could have written this a bit better and less angrily.  I sent ChaosEngine a personal apology.

Now, I've talked to the OP in the gamedev chat once before. One reason he asked this question was because he said he can't afford licensing fees. So I initially suggested writing an engine (a basic one) as a learning experience. If he wants to start off with a middle ware engine, do it but don't expect to be able to sell it legally.

Reasons to write an engine:
- No licensing fees.
- 100% customizable; optimize wherever and whenever.
- As portable as you want/need it to be.
- if it's good, YOU can license it any way you want to!
- Freedom of open source or not, your choice.

Reasons to use a middleware engine:
- You need to slap something together quickly.
- You can afford the licensing fee, and your team is familiar with the engine.
- You lack a team and don't have the luxury or experience to put together a complex engine.
- A middleware engine will likely go through more testing/dev time then your ever will.
- You want see how other engines work before writing your own.

Now, I chose to write my own engine because of the reasons above. With all the frameworks and tools available, writing your own isn't re-inventing the wheel. As for the chef comparison, ifnyournkitchen does not suit you, then build your own, or seek help in doing so. The engine should work for you, not vice versa IMO. My engine suits my needs quite well so far for the time I've put into it.

Lastly, I still stand by my original statement. Using a middleware engine isn't bad especially considering how complex games have come to be today (and frankly can be a better idea considering the options or lack thereof), but this is the first generation of indies who are generally too lazy or unskilled to even write their own engine and couldn't do so if their lives depended on it. 10 years, hell, even 5 years ago, we didn't have such a pitiful excuse to rely on so much.




#5192316 Building A Game Engine + Game

Posted by blueshogun96 on 11 November 2014 - 04:43 PM

You are in no position to even contemplate creating a game engine. Use an existing one such as Unity.
Then start making simple games such as Tetris or Hangman or Pac Man.

You need to learn to walk before you learn to run. Your first project isn’t going to be the game of your dreams. I still haven’t made my dream games from 20 years ago (mostly because a lot of fun new ideas have come in the meantime)—I never expected to just start there. You have to work up to it.

You should not plan on starting a “real” project for at least a year, but 2 or 3 is better. Trying to make your first project be your dream game is the best way to absolutely ruin that dream and frustrate yourself during the learning process. That’s like me trying to build my dream house without ever having built a house before. Even if it looks close to what I want, I wouldn’t trust it to hold up against a strong wind.


L. Spiro

 

While I don't necessarily agree with the first two sentences (which I will explain in a moment), but L. Spiro still has a point.  You mentioned that this is just for practice/fun, so by all means start off small.  Then if you want to tackle something larger, go for it.

 

I personally don't like the idea of beginners using a pre-written middleware engine in their first game, but others do.  Back when I first started (and many of us), we couldn't rely on some middleware engine to make up for our minimal experience.  Call me old fashioned, but only wimps have to rely on an engine (and tbh, I believe that many devs in this day and age with such easy access to middleware engines lack the talent/skill to do it themselves, nor are they interested in learning to do so).  If you want to use C# and Unity, go ahead.  It might actually be a better fit for what you want, however it's not black and white; meaning just because you're a newbie doesn't mean that you should use a middleware engine and nothing else.

 

I recommend trying both for yourself, then making your decision based on your experience, not everyone else's.

 

Shogun.




#5189349 Error: unique_ptr constructed with null deleter pointer

Posted by blueshogun96 on 27 October 2014 - 01:23 AM

After a few minutes of trial and error over the chat with Washu, finally got it working.

#include <iostream>
#include <unordered_map>
#include <memory>


template <class T>
class my_list
{
public:
	my_list() : m_counter(0) {};
	~my_list() {};

	uint64_t add( T* resource, void( *delete_func )( T* ) )
	{
		//std::unique_ptr<T, void(*)(T*)> p( resource, delete_func );
		//m_map[m_counter++] = std::move(p);
		m_map.emplace( ++m_counter, std::unique_ptr<T, void(*)(T*)>( resource, delete_func ) );

		return m_counter;
	}

	T* get( uint64_t id )
	{
		auto itor = m_map.find( id );

		if( itor == m_map.end() )
			return nullptr;

		return itor->second.get();
	}
private:
	std::unordered_map<uint64_t, std::unique_ptr<T, void(*)(T*)>> m_map;
	uint64_t m_counter;
};

template <class type>
void delete_impl( type* ptr )
{
	delete ptr;
}

int main( int argc, char** argv )
{
	my_list<int> list;
	
	int* int_ptr = new int(5);
	uint64_t id = list.add( int_ptr, delete_impl<int> );

	int* i = list.get(id);

	std::cout << int_ptr << std::endl << i << std::endl;
	std::cout << "Value is: " << *i << std::endl;

	return 0;
}

Tested this out.  No fuss, no leaks, no BS.  Washu nailed it in his response. 

 

Thanks everybody, I appreciate it! smile.png

 

Shogun.




#5189203 .mp3 stream to .wav stream

Posted by blueshogun96 on 26 October 2014 - 05:28 AM

Your post doesn't tell us exactly what you want to do, so I can only assume at this point.  What language?  What purpouse/intent, etc?

 

Why bother converting a .mp3 to .wav at runtime?  Is this for a game, or what?  If so, then just convert a .mp3 using a tool.  Second, the .mp3 format is not publicly documented because of patenting/licensing.

 

Shogun.




#5184494 FBX load model cube.

Posted by blueshogun96 on 01 October 2014 - 11:42 PM

Once you have figured it all out

 

Isn't that your job?




#5172337 Simple skinning example?

Posted by blueshogun96 on 08 August 2014 - 01:58 PM

If you are using glVertex3f and friends, then you are *not* using the latest version of OpenGL.  You are, in fact, using legacy OpenGL.  Jordan already beat me to it (darn you sir) and I do recommend his link.

 

If you prefer to use legacy OpenGL (2.1) over core OpenGL (3.0+), then okay.  Occasionally, there may be a good reason for using legacy OpenGL.  For my latest title, I used legacy OpenGL to keep portability to OpenGL ES 2.0 easy (but it was still a mistake I regret).  

 

If you need a tutorial on bone animation, check out this these: 

http://www.codesampler.com/oglsrc/oglsrc_11.htm#ogl_skinning

http://content.gpwiki.org/index.php/OpenGL:Tutorials:Basic_Bones_System

http://prideout.net/blog/?p=56

 

Hope this helps,

 

Shogun.




#5168198 How dangerous is returning a initialized pointer in C++?

Posted by blueshogun96 on 21 July 2014 - 01:10 PM

Okay, I don't quite understand why you are doing things this way.  You declare a global pointer, then use it to initialize the same global pointer.  Why?  if gEngine is not allocated, then calling ::Create is just going to crash.

 

I use C++ myself, but this is how I would do it instead.

void CreateEngine()
{
   gEngine = new EngineAPI();

   /* Do error checking here */
}

What you are doing appears to be quite unnecessary.  Is there a particular reason you want your engine this way?

 

Shogun.

 

EDIT: One more detail.  If you are returning an initialized pointer from C++ to C#, that is a bad idea.  C++ has it's own code routines for initializing a pointer via "new", whereas C# is undoubtedly different, so calling delete on a C++ pointer in C# is potentially dangerous.  Think of it this way, would you use malloc() for a C pointer, then deallocate it with delete in C++?  That is a VERY bad idea, and I would not recommend it.




#5166241 How much more work is needed for an S or C corp?

Posted by blueshogun96 on 11 July 2014 - 10:21 AM

So far, I have the gist of what makes a corporation different than an LLC, and the main difference between an S corp and a C corp. what I haven't yet grasped is how much more work it takes to run, and maintain a corporation, especially a C corp.

If I may ask, are there any members here that have experience starting and/or running a corporation (especially a C corp)? Thanks.

Shogun.


#5157737 With OpenGL, should I use GLut or SDL?

Posted by blueshogun96 on 03 June 2014 - 01:03 AM

If your ultimate goal is to create games that you want to sell and redistribute, don't use GLUT (unless you absolutely HAVE to), and chances are you will not have any solid reasons to use it.  SDL has much more to offer as a game dev then GLUT does.  As it was already mentioned, GLUT is really old and is not actively maintained.  SDL, however, is and is much more suitable for games as it was largely inspired for such usage.

 

In my experience, I have experienced better control and performance using SDL.  GLUT is widely supported on nearly every OS, but implementing controls using GLUT is not feasible to say the least.  I wrote a very simple game using GLUT on Windows once, and thought it worked fine for the most part, but when I ported it to other OSes, the controls were not nearly as smooth for what a game should have, because they were not suited for games (the keyboard timestamp feature will annoy you and everyone else who plays your game; also, the mouse input is not very smooth or accurate enough).  SDL takes a bit more work to setup, but it's worth it.

 

Lastly, using GLUT, you are limited to legacy OpenGL, afaik.  With SDL 2.0, you can easily create a context for the latest OpenGL version you want/need.  This should be a deal breaker for GLUT in most cases alone.

 

Before I wrap up my response, I will give a small defense for GLUT.  I actually have my latest game using GLUT atm.  The reason why I chose GLUT (at the time at least) was because it was easy to setup, and my game in particular with it's mechanics were much easier to get up and running using GLUT.  Another reason is that GLUT's borderless window was proven invaluable when deving and debugging on MacOSX.  Lastly, I initially started writing my game on MacOSX, not knowing much of anything about OpenGL for Mac.  GLUT just felt right at that moment, and it ultimately saved me much time, energy, frustration and needless hassle (there are some features in my game I never would have considered if I didn't use GLUT), but ultimately, using GLUT in a commercial game comes with a price.  Since GLUT is not actively maintained, you are risking future compatibility with new OSes.  The same old glut32.dll or GLUT.framework is not guaranteed to be working on the next Windows or MacOSX, respectively, due to possible removal of a specific API or something.  That probably won't happen, but it can, and it's not worth the risk, IMO.  When it's time for the release, I will likely switch to SDL to avoid that potential land mine.

 

My recommendation to you is to learn the basics of SDL 2.0.  Don't bother with the deprecated SDL 1.x, and it's easy to get the two confused as many things have changed for the better, causing some functionality not to work (Example, if you want SDL 2.0 controller functionality, use this, not the legacy stuff because it won't work).

 

Don't worry about GLUT or legacy OpenGL.  If your card/drivers support it, start learning OpenGL 4.1 or later.

 

Shogun.




#5155027 Templates causing linker errors.

Posted by blueshogun96 on 21 May 2014 - 04:37 AM

It's not missing, but I solved the problem though.

 

The template functions needed to be moved from a .cpp to a .inl and the functions needed to be inlined.  Then include the .inl instead of .hpp, and that solved everything.

 

Shogun.




#5154856 when do you kill an idea?

Posted by blueshogun96 on 20 May 2014 - 12:14 PM

I only scratch an idea or project once I find out that the idea is not feasible.  In fact, I am always considering this possibility and I'm prepared to scratch any of my current projects after evaluating their feasibility, marketability, etc.  When I was a naïve programmer, I had tons of ideas, and only a few were even worth pursuing.

 

I'll give you a personal example.  At one point, I thought of making my own game, which would be a puzzle bobble clone, and have the best puzzle bobble clone ever!  After realizing that a) there were more than enough clones, b) it would be hard enough to convince people to buy my clone and convince them that mine is so much better than the others and c) I could create an original idea that could be a better success, I scratched the entire project completely.  I've done the same with a side scroller and a few others I had initially planned.  Although I'll be honest and say that I've never scratched a project that I was nearly completing.

 

As for your own opinion of your game, I'd say finish it based on other people's feedback (that's if you're planning on selling it).  You personally might not find your game to be fun, but others might.  Since I don't know anything about your game, I can't judge it personally.

 

Shogun.






PARTNERS