This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

21

Other Projects / Re: [Demo] Zombie Grinder

« on: July 24, 2012, 10:44:13 am »

How do you feel about youtube monetizing?  Probably won't do this, but would you approve of play-through videos that are monetized?

Really couldn't care less lol.

22

Other Projects / Re: [Demo] Zombie Grinder

« on: July 24, 2012, 01:58:11 am »

Also just for the funz;

Super Duper Special Hidden Key For Special Awesome Hats For ZFGC
P25GR-WAUA0-MQR9X

23

Other Projects / Re: [Demo] Zombie Grinder

« on: July 24, 2012, 12:26:37 am »

www.zombiegrinder.com

Just thought I would post the sites new URL :3.

Also come join in, games pretty active now, got something in the region of 10000+ accounts registered in the last 2 months or so :3. Usually have 15-20 people online at a time, quite often a lot more.

24

Entertainment / Re: Battle.net IDs - Diablo 3

« on: May 19, 2012, 01:25:14 am »

!@#$% it, I bought it, everyone was going on about it D:

Infinitus#2902

25

Entertainment / Re: Portal 2 custom maps

« on: May 14, 2012, 05:16:45 pm »

Puzzle Editor?  Is this a new tool, or is it like...integrated into Hammer?

Part of the game now, basically a very dumbed down stylized level editor :3

26

Entertainment / Re: Facebook has a new chat feature...interesting

« on: May 09, 2012, 07:24:51 pm »

Crap.

27

Coding / Re: Building a Game Engine Help

« on: May 07, 2012, 10:57:49 am »

Oh yeah, Infini, I have been studying your code. For one, your PlatformMain() entry point is somewhat unnecessary. You can use main() for creating Win32 App, it even says so on the Microsoft Docs. If you want to get rid of the console window, you can just use:

I think you missunderstand the point of PlatformMain(). The main point of my engine is to make it entirely cross-platform, each platform code stub implements the main method differently (setting up different bits of the environment specific to the platform) and implements error recovery, it then calls the PlatformMain which contains the "generic" platform-agnostic code for the actual game.

It has nothing at all to do with the subsystem being compiled to. The compiler has no knowledge of PlatformMain it dosen't do anything based on it, it's just a nicer system to hide away the platform specific code.

I also intend to have NO platform specific code outside of the platforms folder, allowing porting to be possible just by copy/pasting a platform folder and updating it to support the new platform. No #ifdef WIN32 etc are allow anywhere outside the platform folder, thus the PlatformMain is neccessary.

Also, I noticed you use
#pragma once
as your control guard. Not sure if you know, but I've read that it's best to use

Actually no it isn't.

This holds true for years and years ago, but nowadays all of the standard C++ compilers fully support #pragma once, and make optimizations based on it. All the compilers I'm targeting (Intel, GCC, MS) support it so its fine :3.

The header guard system is a left over from when only MS supported the definition.

28

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 11:01:55 pm »

Your whole code is making me want to try do the same (make everything from scratch). I always thought I was speed obsessed until I saw you, you're extreme. I want to start making a game already though...

Bad idea .

I'm just anal about my code, I hate using libraries that are out of my control (hence no stl).

It's a bad move really, reinventing the wheel is pretty dumb lol.

29

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 10:28:26 pm »

Well my brain exploded looking at all of this O_O I'm still looking at it and it's very interesting. I have a lot to learn. How long have you been working on it? And where did you learn all of this from? Do you read books on this all?

Nope, never found many programming books worth reading :S. Most are terrible attempts at ripping money out of people trying to learn.

As for the engine, start writing it about a month ago, put in an hour or so every other day.

I already have a limit of 60 FPS and for Win32 I use GetTickCount(). I had to call Sleep() anyway, so I could lower my CPU usage.

ps. GetTickCount() is very inaccurate, resolution is usually as around 10ms, sometimes more, sometimes less. Check the MSDN article for information. QueryPerformanceCounter is probably a better idea.

Also sleep gives up your entire timeslice, and its only guarantee is that it will sleep for at "least" the amount of ms you give it, usually its more. Normally it should be fine, but its worth keeping an eye on if your performance gets bad.

30

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 10:04:30 pm »

If you want an example, look in memory.h, callocator.h and cheapallocator.h from one of my projects here

Wow, this is very hard to follow. Just wondering, how necessary is this?

Definitely not necessary, you can get away with new/delete fine lol, I'm just going for crazy speed.

You did ask for an example of my functions . lol

31

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 09:29:23 pm »

As in;

MyGameEngine engine;
engine.Run();

rather than;

MyGameEngine* engine = new MyGameEngine();
engine->Run();

Top is allocated on the stack and is basically instant, bottom one is allocated on the heap and is slow as hell.

If you want an example, look in memory.h, callocator.h and cheapallocator.h from one of my projects here;

http://binaryphoenix.com/svn/public/Crossplatform%20Game%20Engine/Engine/

Does an error code mean something like my idea of having a boolean return that makes its way go back to the main function? I generally use that to find errors, then in the debug version of my project, I have the console activated and I use std::cout and cin.get() so I can assess what happened.

Pretty much yes.

32

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 09:06:44 pm »

1) Circular dependencies happen when you try to include header A in header B and header B in header A. I was taught not to try to include any of your own made headers in other header files. It is preferred to use forward class declarations, unless it is not possible. With forward declarations it is also required to have pointers to classes as variable types. When you don't use pointers you need to include the header file of the class you are importing. Try to include the *.h files in the *.cpp files. 

I figured he was talking about circular references between classes, not in the more abstract "header files" deal.

But if you are talking about that, solid advice above, forward declarations are the way to go.

2) Preload issue, you could try to create smart pointers that keep track of the number of times a reference is stored. Next you can use a Texture manager/Texture factory to load and manage textures.

Never get over reliant on smart pointers, they tend to instil bad programming practices, and they are several factors slower than accessing normal pointers.

It is good to allocate some memory before hand, but too much that you will never use is not good either.

Totally disagree there. I think its far better to allocate a lot of memory that you may not use, than slow the game down horribly for the user when you don't have enough.

Few users have such a low amount of RAM these days that it makes any difference to them. Not to mention with games you tend to be in more or less exclusive control of the computers resources.

Which you will catch or let it propogate up the execution stack. Exceptions are the way to go here.

Huuum, totally disagree with this, error codes for functions are IMO a far better way to go. Exceptions in C++ have HUGE overhead (mainly because they infer several context switches by the OS), they shouldn't be used for general error handling, only in exceptional circumstances (exception,exceptional,etc).

33

Coding / Re: Building a Game Engine Help

« on: May 05, 2012, 09:02:15 pm »

I need help because I don't really know how exactly the best way to build it would be. My current idea resolves around circular dependencies, which I want to avoid. Generally, I have a header, game.h

Circular dependencies are unavoidable at times, there is nothing inherently wrong with them as long as you make sure you tear them down correctly.

I generally wanted to have my textures stored in the core so that some textures could be preloaded during some levels and used in the next. One problem is the circular dependency that is being created. Another is that I have to be careful to know which textures are preloaded when. I'm just having trouble coming up with concepts.

I would personally have a texture manager, and have that passed between the entities that need it, rather than a root "Game" object that everything goes through for everything (I imagine you would do the same for audio and such?).

As for knowing what textures are preloaded, why not use texture "handles". When a texture is requested that's not loaded you just return a "default" texture, and spawn off a thread to load the new texture and replace the default one when its ready.

tbf through that's kind of unnecessary, what situations are you going to come into when you need to load textures at runtime (I assume most would be loaded when the map is loaded?)? If all else fails, loading textures at runtime is unlikely to take more than a few milliseconds, unnoticeable to the player.

Another thing I don't understand is memory management. How do I handle that? Should I try to allocate everything as soon as possible?

Number one rule of game developer, always avoid allocating at runtime when possible, memory allocation is one of the slowest things you'll find in any game. Especially on consoles. Try and load everything before hand, or better yet, stick em in the stack.

Personally what I do is write my own allocation routines (and then override new/delete to assert, to make sure people don't accidently use them). These allocation routines typically allocate in huge blocks of about 64mb each, and then portion them out and return them. Far faster than malloc'ing them at runtime.

Also, in case that the player has an error, how do I handle that? Should I make some functions boolean that return false so that my main function can end peacefully or should I just use a function like exit()?

If the game can continue from the error, ignore it. Better to allow the player to keep playing than drop out (obviously don't do this in debug mode tho).

If you want to find a nice way of showing fatal error messages to the user, checkout the use of SetUnhandledExceptionFilter on windows and setjmp/longjmp on any other platform.

34

Graphics / Re: Ocarina of Time to A Link to the Past Style Project (Great Deku Tree Finished!)

« on: May 03, 2012, 04:07:49 pm »

Gotcha. If you do, make sure you do it properly . Be a shame to let this amazing sprite work go to waste!

35

Graphics / Re: Ocarina of Time to A Link to the Past Style Project (Great Deku Tree Finished!)

« on: May 03, 2012, 04:03:39 pm »

So are you actually coding this as a game? Or just spriting everything?

36

Graphics / Re: Creative way to display health in a HUD...?

« on: April 28, 2012, 02:42:33 pm »

On-screen tells based on health. Like 50 or below, maybe have red around the edges, pulsing like a heartbeat, and then when you're below 10, have it go black and white?

I see what you did thar

37

Feedback / Suggestion

« on: April 26, 2012, 11:00:21 pm »

Big ass motherfucking link to the forum on the portal somewhere, or some more obvious way of getting to it from the portal page.

The link to the forum at the moment is hidden behind a lot of crap in the menu (I know I wrote it D:, we all make mistakes, etc). With the addition of the chat bar it further hides it. A more directly and obvious link for people visiting the site can only be a good thing.

/randomthoughts

38

Coding / Re: Playstation Suite

« on: April 19, 2012, 10:34:25 pm »

Nah, I mean emulators in the sense of emulators of various consoles that run on the Vita. The main thing that makes emulators so quick nowadays is dynamic recompilation, essentially taking the machine code that the console's looking to run and converting it to a format that's friendlier to the CPU of the machine you're trying to emulate it on during runtime. It's sort of like JIT compilation, actually, with a middleman bytecode language, but instead of bytecode it's machine code for an alien platform.

(ps. I work in the toolchain team -> we write all the compilers for the consoles :3, just sayin).

I want to make Vita stuff, though. I was under the impression that the Mini's were ran in the PSP emulator or something that didn't allow you to leverage the full power of the Vita.

Yeh they are, they run on all sonys consoles, but inside an emulator running to the specs of a PSP. It's closer than the SDK though, least you have access to C++ and more low-level control.

The only option is to pretty much use this SDK. I don't think I'll be CPU-bound for my freerunning game, though, much more likely GPU-bound. The only issue is I doubt it'll be running on the Xperia play or the other platforms that it apparently *has* to run on to get to the PSN. Is that true, that it must run on those platforms as well?

If the TRC is anything like the minis it will more than likely have to run to the same performance on all supported platforms. The xperia is actually pretty powerful, I wouldn't underestimate it.

That said, not seen any of the TRC stuff for this yet (not sure if its even been written) so can't really say. Can always shoot them an email or post on the forums if you want to know.

39

Coding / Re: Playstation Suite

« on: April 19, 2012, 10:21:52 pm »

If that's true about no JIT and only a VM, that's a huge bummer. That "crazy executable format" is basically Mono's .NET implementation, which is based off Microsoft's .NET which is considered a standard now, so it's not that crazy.

When I said crazy executable format, I meant its not the .NET format . It's hard to explain what I mean without saying stuff I'm not allowed to.

It would've been nice to see some emulators made on this platform, but because it's not JIT'd those are going to have a lot of issues. Might've been able to have a N64 emulator at decent speeds if it was JIT'd and allowed linking C# dynamically, but I doubt the latter is even allowed in any way, shape, or form.

Emulator (/Simulator) for this platform? Isn't there already one for windows to debug games in? There was when I checked a few weeks ago.

I expected this anyway, but it's still a bit of a letdown. Developers programs for consoles are usually quite expensive.

Not really. I mean if you want to do mini's development all you need is a PSP devkit, and those are loaned out now, they aren't even sold. Theoretically you could probably join for $0, need to prove you know what your doing to some extent tho.

You can always do what I've done as well, grab a devkit (my 360 kit only cost like £400) on the blackmarket. Then approach the first party's when you have something worth publishing.

40

Coding / Re: Playstation Suite

« on: April 19, 2012, 10:11:30 pm »

Do you really need to make games for Mac or Linux? Most gamers use Windows. And C++ and C# are not entirely different so it would not take long to port your codebase over.

You would be surprised actually, especially when it comes to indie games, the linux market is pretty huge. Mac is still pretty tiny tho.

Also C++ and C# are worlds apart. My god I would hate converting a C++ codebase to C#, pretty sure the majority of it would not even be possible either. Especially not with PSS, which (I believe?) dosen't permit unsafe C# code to be run on the devices.

After the beta, we will not have to pay for the program itself, will we?

Programs free I believe, need to pay $99 for publishing contract / debug live on platforms.