Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2461 Excellent

About kop0113

  • Rank
    Advanced Member

Personal Information

  • Role
    Technical Director
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. kop0113

    Developing 2D sports game

    If the genesis style 2D games is what you are looking at then I personally would choose one of the following (in order of preference): C++ and SDL 1 or 2 Javascript / HTML5 canvas C# and just Winforms and the inbuilt paint system. Something like Unity or UE4 is overkill for this and getting your head round their strange 2D orthographic camera in a 3D world kludges may be avoidable if you use a 2D drawing API for your 2D game. IMO you will learn more and have more fun with the drawing APIs than using a 3D engine. Actually, for the last Global Games Jam I developed a 2D topdown Rogue-like soccer game for the megadrive using SGDK (gendev) and DGen/SDL. It was a blast. I love these kinds of games. As a happy bonus it worked on most platforms I tried (Win,UNIX,Android,Mac,iOS) because most platforms have at least 5 genesis emulators available on them haha
  2. kop0113

    Problems with starting out on linux

    I was not suggesting writing your own engine? For example for many projects I have used UE4, I rarely if ever needed to use the editor. I just used the UE4's UBT to generate Makefiles and away I went. Sure, making maps I would use a map editor. You obviously don't need one for code or scripting. There are many professional game engines that do not come with GUI editors. UE3.x was incredibly successful without one after all. Arguably UnrealEd was also a better standalone map editor.
  3. kop0113

    Problems with starting out on linux

    Its not that using Editors is bad if you are a game scripter, but *only* being able to make games by using an Editor is a shame and a massive restriction to making awesome games for new and upcoming platforms. For example we released one of our games to the pluginless web using Emscripten over a year before Unity managed to get its ass into gear and follow suite (UE4 faired a little bit better but only supported 64-bit browsers). If our team could only use Editors, we would have missed out on an excellent opportunity. It isn't an elitist thing. Actually it is more the opposite, I think a lot of game developers these days mistakenly look down on projects that *don't* use editors or big fat IDEs like Visual Studio.
  4. kop0113

    Problems with starting out on linux

    Unity support for Linux is around. (https://forum.unity.com/threads/unity-on-linux-release-notes-and-known-issues.350256/) By Linux they only really mean Ubuntu-current. Portability is quite poor to other distros (especially older kernels like RHEL6 etc). I perhaps blame the closed source nature of Unity and the wild-west style mishmash of libraries in Linux If you cannot run UE4 (because "next-gen" apparently means extremely wasteful of resources) then perhaps try something like Godot https://godotengine.org/ In the long run. As a developer, try to wean yourself away from "Editors". They will often restrict you in the things you really want to do.
  5. Basically, code is code. Simply a text file and nothing will really change that. Sure you may get API breakage but this is rare when using a decent engine. I.e as an extreme case, they will never rename the Actor class to GameActor etc. Whereas things like Blueprint, editor settings, asset import data etc, all get stored as binary data files. If the editor fails to read and munge this correctly, data will be lost. You can use UE4 entirely from your editor of choice. Use the Unreal Build Tool (UBT) to generate either Makefiles on POSIX standard operating systems, or Visual Studio .sln files on Windows. Then just code using that. In VS, you can set the build profiles i.e Debug, Release, Release Editor etc... So, when I need to modify the map, I use the UE4Editor... then I close it and for the rest, just simple Vim editor, gmake and gdb for my code, debug, test cycle. You should never have to click the "Build" or "Run" button from the editor.
  6. Yep, but being able to revert to a previous revision doesn't quite solve things if the latest version of UE4 is simply going to trash the project again next time you open it . Reducing use of editors also has the pleasant side effect of our project being able to play nicer with Git.
  7. kop0113

    Breakpoint Problem, Please!

    Yes, I may have been a bit unduly harsh but for a long time (i.e when I used to use it), Visual Studio did not integrate well with other compilers (until as recent as 2015 IMO). I have had first hand experience with developers whining that in order to port our software to i.e the web via Emscripten or Android via gcc (at the time) they couldn't use Visual Studio and almost refused to learn and use standard tools like CMake. This just added more workload onto myself and others. It has just left me with the bad taste that Visual Studio caters for lazy coders. Obviously this is not always the case, John Carmack is an avid Visual Studio user but unlike some others has in the past tried many, many different development environments to see what worked for him. Same reason why I am not a fan of Unity. It isnt Unity itself but if things go wrong and there is a complexity, the potentially lazy developer brought up learning nothing but Unity will just sit there blaming Unity rather than fixing it. Also, I might add that the Visual Studio tools provided by the PS4 SDK are absolutely terrible. They don't provide it but if they did offer me remote GDB, I would be using it like a shot! Looking around at the community, it actually seems a lot of people don't like the debugger plugin. But this is going off topic
  8. kop0113

    Breakpoint Problem, Please!

    Yes, this one can be a tricky one. Especially since the stack overflows so even the code before the i.e massive array will not run. Something like: void func() { printf("Hai\n"); <---- breakpoint here may not trigger int largearray[999][999][999]; } You may expect the breakpoint to at least trigger before the stack gets overrun but the way programs work means this is not the case. Good fun. Glad you got it solved My gdb when run through the terminal, tells me that the crash is at the '{'. I guess that is correct but not always that helpful! And GDB is a perfectly good debugger. Most gamedevs only use the Visual Studio inbuilt one because frankly... well they simply haven't researched alternatives like gdb, lldb, idb or dbx. The same with compilers, a lot of them simply use Microsoft's cl because it is all they have ever been taught. Also being able to debug remotely (i.e on Android, iOS) via remote GDB has always been a much better solution than any Visual Studio debugger plugins I have had the misfortune to use. Though I would mention that using Code::Blocks rather than Visual Studio purely because your code has too many errors is a bit strange. You might want to look a bit further into that XD.
  9. You might want to just try out both and evaluate for yourself first hand. 1) Unreal allows you to also use C++ rather than blueprints. There are some differences but it can work in a very similar way to Unity. I have used UE4 for many projects now (including work on a port of the engine to FreeBSD) and I probably still couldn't even make a door open in pure blueprints haha. 2) UE4 as a developer can be used entirely without the editor. You basically generate the build scripts via a command-line tool (or the editor) and then use your favorite Editor or IDE to modify the code and then initiate a build via "gmake" or "msbuild". This almost eliminates any chance that UE4's editor will trash your project on a version bump. As an artist or designer (who needs to use the editor), yes the version bump can sometimes disconnect assets and the scene but this is also true for Unity. I actually find that UE4 using C MACROS rather than Unity's C# reflection to be a little bit more robust when connecting scripts to the scene but yep, they both can break. 3) I find UE4 to be a nicer choice for build systems such as jenkins or bamboo and version control. For example in Unity, the build script (written in C#) needs to be compiled by the editor before it can run, this gets messy. In UE4, the Unreal Build Tool can do much of the work, such as initiating a bake or a module can be made that doesn't need the editor to actually load. This makes build VMs more feasible.
  10. kop0113

    C++ Invalid read of size 8

    Some additional tips if it helps: 1) Where possible, try to use std::vector<T> rather than new[]. It is easier to track memory when a resize happens. You also don't need to worry about cleanup (delete[]) so is more exception safe. 2) If performance allows, use std::vector<T>::at(size_t) rather than raw array access []. This is because at() is bounds checked and will throw an exception when going out of bounds. Yes this does have overhead so perhaps use in your game "scripts" rather than engine. The overhead is still much less than C#/Java and they are still perfectly adequate for game scripting. 3) Make use of the VMM on your platform. I.e when memory is no longer used, rather than freeing it, just lock it (mprotect, VirtualProtect) so later access throw an immediate error. I have a quick single file that you can drag and drop into your project that will do this (there are more featureful solutions available though): https://github.com/osen/plank/blob/master/src/plankmm/plank.cpp Remember to turn this feature off for Release builds or your game will inevitably run out of memory 4) If on Linux/UNIX/Mac, have a look at Valgrind, it will help debug these kind of errors (even on the stack). If on Windows, you can try to find a copy of Purify Plus (I haven't seen a copy in the wild for a long time now though).
  11. kop0113

    Unity or Unreal

    For complete beginners or those who do not want to code: Unreal (with Blueprints) For people with experience in high performance native software development (i.e scientific, banking, visualization industry) then Unreal (C++). For more vocational developers or those familiar with things like Java and .NET (VB.NET, C#) then Unity is useful because non-native languages such as VB.NET or C# are far less challenging than C++. For many companies, often they simply don't have any other choice but to use C++ because that is what their middlewhere requires. No point in wasting months writing .NET bindings just to use a specific native library. So Unreal (C++). I still personally recommend the C++ route if your are starting out. It still looks better on a candidate's CV.
  12. In the grand scheme of things, games have often quite simple GUI requirements. I.e a game I recently completed had: Text Button List Box Check Box Granted, for a RTS you might have more complex requirements but for that you will likely need custom GUI components anyway. One alternative is using a "proper" Gui library such as wxWidgets, Gtk+ or Qt. Then use that for the buttons and lists but then render the game in some sort of wxGLCanvas (if using wxWidgets and OpenGL).
  13. You can do OOP with C (check out gobject as an (over engineered) approach). Likewise you can do procedural development with C++ but still benefit from safety and convenience (i.e smart pointers, STL / vectors) Most of my middleware work is in C (eases binding to other languages and the hardware) but I would classify more than 90% of my code to be Object Oriented in design. i.e C: struct Player *p = PlayerCreate(); PlayerDamage(p, 13); PlayerDestroy(p); vs (non-exception safe) C++ Player* p = new Player(); p->damage(13); delete p; As for which one is better... people generally agree that breaking things up into objects makes a project easier to navigate because you have a common design that you can make assumptions upon.
  14. 1. Visual Studio is pretty bloated these days so there are likely going to be bugs. However, the compiler itself is pretty solid so it is quite unlikely it will "inject" errors into your code. 2. As well as the latest, I generally keep a copy of 2010 around. Purely because quite a few large projects still require it (have not been updated to fix build issues for later VS versions). For example building the UE4 engine from scratch, Emscripten, Clang etc... It also means that my users do not need to install the latest Microsoft C++ runtimes to execute my software. Before 2010 came out, I kept a copy of Visual C++ 6 for a similar reason (as did much of the world tbh). 3. Command line Git is generally a lot more flexible. https://git-scm.com/download/win Also, Git is the tool. GitHub is a commercial "cloud" service. Alternatives are assembla, bitbucket or codebasehq. Also GitHub provides subversion access too if your team use a mix of SVN and Git. 4. Extensions and Visual Studio change too much. I wouldn't bother.
  15. kop0113

    When To Use Pointers?

    If you passed in Objects rather than pointers to objects, they would be copies. So if you modify them or get data from them, you would be modifying the copies. The original ones (perhaps a core part of you engine) will remain unchanged. This is obviously an issue if you added (i.e) a new Physics object to the *copy* of the PhysicsComponent, the original PhysicsComponent will remain unchanged causing issues later when you query the original expecting the additional Physics object to be registered. In C#, I see a lot of inexperienced developers make the same mistake for "boxed" value types like structs. They modify a Vector3 for example, pass that Vector3 into some other class but then modify the original Vector3 again, expecting it to change the Vector3 in the other class. In C# *everything* acts a pointer apart from structs/boxed types. // C# using a library where Vector3 is a struct, value type Vector3 v = new Vector3(); player.position = v; v.x = 99; // player.position.x is not 99 // C++ (avoiding pointers) Vector3 v; player->position = v; v.x = 99; // player->position.x is not 99 // C# using a library where Vector3 is a class Vector3 v = new Vector3(); player.position = v; v.x = 99; // player.position.x is 99 // C++ (using pointers) Vector3 *v = new Vector3(); player->position = v; v->x = 99; // player->position->x is 99 Perhaps refer to the following complexity in C# to better understand how C++ handles this situation: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing When people say do not use pointers in C++... that simply isn't feasible. Perhaps they mean they use smart pointers with references as parameters instead? Either way, unless they only stick to OpenGL's GLuint type system, I cannot see them avoiding pointers when dealing with 3rd party C libraries such as SDL. Would be cool to be proved otherwise. Can anyone point me towards a largish project where this is the case?
  • 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!