• Content count

  • Joined

  • Last visited

Community Reputation

1164 Excellent

About Finalspace

  • Rank

Personal Information


  • Github
  1. Update v0.4.4 alpha: New: [Win32] Implemented argument parsing for WinMain and wWinMain Fixed: Corrected small things for doxygen Changed: Renamed CopyAFile to FileCopy Changed: Renamed DeleteAFile to FileDelete Note: Next update while take a while, because i want to get the linux implementation to the same level as the win32 implementation.
  2. Update v0.4.3 alpha (Big one): New: Introduced IsAtomicCompareAndExchange Added: [Linux] Implemented IsAtomicCompareAndExchange for all 32 and 64 bit integer types Added: [Win32] Implemented IsAtomicCompareAndExchange for all 32 and 64 bit integer types Added: [Win32] Loading gdi32.dll dynamically for ChoosePixelFormat, etc. Added: [Win32] Loading opengl32.dll dynamically for wglGetProcAddress, wglMakeCurrent, etc. Fixed: [Win32] Adding memory fence for AtomicReadWriteFence on non-x64 architectures Fixed: [Win32] Adding memory fence for AtomicReadFence on non-x64 architectures Fixed: [Win32] Adding memory fence for AtomicWriteFence on non-x64 architectures Fixed: Solidified descriptions for all Atomic*Fence Changed: Enabled FPL_FORCE_ASSERTIONS will ensure that C asserts are never used, because it may be compiled out. Changed: Removed all FPL_WIN32_ kernel32 macros and replaced it with normal calls. Changed: [Win32] Changed a lof ot the internals State/Planned: [Linux] Implement all non-window based functions [Win32] Use dynamic library for all the things, so you simple just link to kernel32.lib and thats it (Partially done) [Win32] DirectSound/XAudio2 audio output + api
  3. OpenGL The simplest OpenGL example

    Check out: Its a single header file library which creates a window and a legacy or modern opengl rendering context. You wont get it easier than this.
  4. November 2017 GameDev Challenge: Pong!

    You can always do the challenges months/years later, but you wont get any rewards (trophies etc.). Regarding the second question: It depends how to challenge is limited. If a challenge is limited to C++ only - which the one from oct. and nov. isnt´t you can write it in every engine/framework/language you want. But to be clearly sure, you have to read the challenge requirements - for example, some require special art.
  5. Update v0.4.2 alpha: Added: [Linux] Started linux implementation Added: [Linux] Memory allocations Added: [Linux] Atomic operations Added: Check for C++/11 compiler and fail if not supported Added: Nasty vstudio 2015+ workaround to detect C++/11 Added: &= operator overloading for enums Changed: AtomicCompareAndExchange argument "comparand" and "exchange" flipped. Changed: constexpr is now fpl_constant to make clear what is a constant Removed: [Win32] CreateDIBSection is not needed for a software backbuffer Fixed: [Win32] Software rendering was not working properly. Fixed: Some AtomicCompareAndExchange signatures was still AtomicAndCompareExchange State/Planned: [Linux] Implement all non-window based functions [Win32] Use dynamic library for all the things, so you simple just link to kernel32.lib and thats it [Win32] DirectSound/XAudio2 audio output + api Still unsure: I dont like callers requiring C++/11 just for constexpr and enums, should i go back to C++ 1997/11? I still dont like the nested namespaces, its just a couple of functions and types, one namespace is enough and this i could make optional if i want to. But i dont know...
  6. Debate: Proper Time For Microtransactions?

    My oppinion: - Single player games on any platform should never ever introduce microtransactions in any way. - Multi player games can have microtransactions for cosmetics or speeding up the grinding only but for nothing else. - DLC´s are fine when the core game does not feel limited/incomplete and the expansion actually enriches the game by at least 1/3.
  7. This thread is for annoncing new releases only, so its appreciated to create a seperate thread for discussions. But thanks for the tip with the releases, i will try to do that. Seems i have forget about that entirely, since i am using another version control system at work... What do you mean with warning level 3 instead of 4? (Visual Studio Project configuration?)
  8. Update v0.4.1 alpha: Cleanup: Internal cleanup Changed: All the settings constructors removed and replaced by a simple inline function. Added: Added native C++ unit test project to demos solution Fixed: FPL_OFFSETOF was not working Fixed: All file size macros like FPL_MEGABYTES was returning invalid results. Removed: FPL_PETABYTES and higher are removed, just because its useless. State: I cleaned up all the internals so i have a single block per platform and fixed some small bugs. Also i decided to continue with the subnamespace style - one nested level is fine. Next big thing will be audio output using directsound or xaudio and implementing the linux platform.
  9. Nested namespaces useless typing?

    I am talking about nested namespaces in C++. For example: // One nested namespace namespace my { namespace paths { const char *ExtractFileName(const char *path); }; namespace strings { size_t GetAnsiStringLength(const char *str); }; }; // Multiple nested namespaces namespace my { namespace system { namespace io { namespace path { const char *ExtractFileName(const char *path); }; }; }; namespace strings { size_t GetAnsiLength(const char *str); }; }; // Single namespace with category prefix namespace my { const char *PathExtractFileName(const char *path); size_t StringGetAnsiLength(const char *str); };
  10. November 2017 GameDev Challenge: Pong!

    Looks really great, i will try to test it when i get home.
  11. Nested namespaces useless typing?

    Do you think that C++ api structured by nested namespaces are a good thing? Or do you see its just useless typing and it should rather have a prefix or something? Or do you think that one or two levels are just fine? What do you think? I personally think that C++ namespaces are there to prevent conflicts between other api´s and for nothing else. But for medium to large size api´s one nested level is fine. Too long: my::IO::Path::Combine(my::IO::Path::GetHome(), my::IO::Path::ExtractFileName(...)); Fine: my::Paths::CombinePath(my::Paths::GetHomePath(), my::Paths::ExtractFileName(...)); Better (using namespace my): Paths::CombinePath(Paths::GetHomePath(), Paths::ExtractFileName(...));
  12. Update v0.4.0 alpha: Changed: All FPL_ENABLE_ defines are internal now, the caller must use FPL_NO_ or FPL_YES_ respectivily. Changed: AtomicCompareExchange is now AtomicCompareAndExchange Changed: InitFlags::VideoOpenGL is now InitFlags::Video Added: Software rendering support Added: VideoDriverType enumeration for selecting the active video driver Added: video::GetVideoBackBuffer with [Win32] implementation Added: video::ResizeVideoBackBuffer with [Win32] implementation Added: FPL_PETABYTES macro Added: FPL_EXABYTES macro Added: FPL_ZETTABYTES macro Added: FPL_YOTTABYTES macro Added: FPL_MIN macro Added: FPL_MAX macro Added: MutexCreate with [Win32] implementation Added: MutexDestroy with [Win32] implementation Added: MutexLock with [Win32] implementation Added: MutexUnlock with [Win32] implementation Added: SignalCreate with [Win32] implementation Added: SignalDestroy with [Win32] implementation Added: SignalWait with [Win32] implementation Added: SignalWakeUp with [Win32] implementation Added: GetClipboardAnsiText with [Win32] implementation Added: GetClipboardWideText with [Win32] implementation Added: SetClipboardText with [Win32] implementation for ansi and wide strings Added [MSVC]: AtomicExchangeS32 (Signed integer) Added [MSVC]: AtomicExchangeS64 (Signed integer) Added [MSVC]: AtomicAddS32 (Signed integer) Added [MSVC]: AtomicAddS64 (Signed integer) Added [MSVC]: AtomicCompareExchangeS32 (Signed integer) Added [MSVC]: AtomicCompareExchangeS64 (Signed integer) Fixed [MSVC]: AtomicExchangeU32 was not using unsigned intrinsic Fixed [MSVC]: AtomicExchangeU64 was not using unsigned intrinsic Fixed [MSVC]: AtomicAddU32 was not using unsigned intrinsic Fixed [MSVC]: AtomicAddU64 was not using unsigned intrinsic Fixed [MSVC]: AtomicCompareExchangeU32 was not using unsigned intrinsic Fixed [MSVC]: AtomicCompareExchangeU64 was not using unsigned intrinsic Implemented [Win32]: GetProcessorCoreCount Implemented [Win32]: Main thread infos Performance [Win32]: GetProcessorName (3 loop iterations at max) State: Its almost feature complete for Win32, only audio output is missing. Next i will clean up all the ifdef madness to get a more clean code structure - so i have a single ifdef block for each platform/backend. Also i am thinking about removing the sub namespaces, just because its so much useless typing for no reason.
  13. Update: Renamed: All memory/library/threading functions Renamed: CopyFile/DeleteFile renamed (Stupid win32!) Renamed: All internal opengl defines renamed, so that it wont conflict with other libraries Fixed: [Win32] strings::All Wide conversions was not working properly Removed: [Win32] All undefs removed Changed: [Win32/OpenGL] Check for already included gl.h Added: Basic threading creation and handling Todo: Create full documentation / upload doxygen documentation. Win32 audio output + api Win32 mutex / condition + api Win32 clipboard get/set Linux platform support
  14. 1/2. I already have the signature of passing in a buffer in all functions, but i (browser crashed in the middle of the sentence) thought i might be a good idea to support passing nullptr as the destination buffer. But you are right it was a bad idea, i should support returning a object instead, string memory allocated on the heap - which is the same std::string does under the hood. But overall my goal was to let the user decide how to handle the memory - not the library. So using a buffer always and never allocate memory would be more sane for that goal. 3. I copied it from stackoverflow, i just wanted a quick result for the moment. I have not thought this through by any means but i will when i feature complete the library, which will take a while because i want linux support as well.
  15. Reinventing the wheel

    Neither quicksort or std::vector is a wheel - not even close. Quicksort is okay right know, but in the future i expect we have sorting algorythms which are 1000 times faster. Vector are based on a good idea (dynamic growing array), but it has a bad api, bad control of memory and the implementation is a nightmare of macros and templates, impossible to debug or to find errors which are related. Other languages does this much much better, but even those are still not a wheel. Each one have weaknesses and flaws, some have a great api but bad technical implementation and vice versa - the "wheel" has nothing of that sort, its near perfect. Sure its the best we have right know, but like casey sayd - nothing in the past 30 years of game development is a wheel. I would go even further and state that nothing in the past 30 years of any software development is a wheel, especially the web which is the clunkiest square wheel ever made. So we need people which question things and try to make the next wheel. If nobody tries that, we never get a wheel. Its as simple as that.