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.
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.
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
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.
Also, I noticed you useActually no it isn't.
#pragma once
as your control guard. Not sure if you know, but I've read that it's best to use
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 .
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.
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.
Definitely not necessary, you can get away with new/delete fine lol, I'm just going for crazy speed.QuoteIf you want an example, look in memory.h, callocator.h and cheapallocator.h from one of my projects hereWow, this is very hard to follow. Just wondering, how necessary is this?
MyGameEngine engine;
engine.Run();
MyGameEngine* engine = new MyGameEngine();
engine->Run();
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.
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.
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.
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).
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.hCircular 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?).
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.
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).
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
(ps. I work in the toolchain team -> we write all the compilers for the consoles :3, just sayin).
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.
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.
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.
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.
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.