Finalspace

Member
  • Content count

    502
  • Joined

  • Last visited

Community Reputation

1170 Excellent

About Finalspace

  • Rank
    Advanced Member

Personal Information

Social

  • Github
    f1nalspace
  1. VStudio links to wrong DLL?

    Forget it. I changed to dynamic runtime linking and now it works - no idea why VC cannot link properly to the correct library.
  2. I am getting a crash in a FFMPEG applications, when i use linked shared libraries. It compiles just fine, but when i execute the application i get a exception that the function "sws_freeContext" is not found in "swresample-3.dll". But the function is in a totally different library called "swscale-5.dll", because the function is from the software-image-scale library, hence the prefix "sws" - so visual studio does bullshit here, linking to the wrong DLL? Looking into the swscale-5.def and the swresample-3.def i can clearly see, that the functions are properly defined: swresample-3.def (Audio resampling) EXPORTS swr_alloc swr_alloc_set_opts swr_build_matrix swr_close swr_config_frame swr_convert swr_convert_frame swr_drop_output swr_ffversion swr_free swr_get_class swr_get_delay swr_get_out_samples swr_init swr_inject_silence swr_is_initialized swr_next_pts swr_set_channel_mapping swr_set_compensation swr_set_matrix swresample_configuration swresample_license swresample_version swscale-5.def (Image format conversion) EXPORTS sws_addVec sws_allocVec sws_alloc_context sws_alloc_set_opts sws_cloneVec sws_convVec sws_convertPalette8ToPacked24 sws_convertPalette8ToPacked32 sws_freeContext sws_freeFilter sws_freeVec sws_getCachedContext sws_getCoefficients sws_getColorspaceDetails sws_getConstVec sws_getContext sws_getDefaultFilter sws_getGaussianVec sws_getIdentityVec sws_get_class sws_init_context sws_isSupportedEndiannessConversion sws_isSupportedInput sws_isSupportedOutput sws_normalizeVec sws_printVec2 sws_scale sws_scaleVec sws_setColorspaceDetails sws_shiftVec sws_subVec swscale_configuration swscale_license swscale_version Also i double checked my FFMPEG shared build and the libs match the shared dll´s properly - so i have no idea, what the heck is wrong. Can i force visual studio to use a specific .DLL/.DEF match in the linking... ??? The (Shared, Dev) build i use is https://ffmpeg.zeranoe.com/builds/ And i just want to compile https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/1b5d3c0:/fftools/ffplay.c with a new visual studio project and SDL2.
  3. Rip internet 2017-12-14

    There is something missing here: Since net neutrality is gone, the ISP´s have legally full control to do whatever they want to do without any real concerns. - They can legally full on deny access to any arbitary sites/services/server however they want. - They can legally prefer their services over competitor services by changing the priority/speed of things or full on deny competition services all together. - They can legally throttle or limit your internet connection arbitary. (These may not be true for all ISP´s!) - They can legally increase the costs of your internet connection, which will happen automatically when the first two points are invoked. So is this a good thing? For the money of the ISP´s yes, for users? No definitily not. I dont mind paying a bit more for streaming and such, but i fully disagree that services/connections get throttled or limited in any but i will expect this will happen in this to next year dramatically - including other countries following and dropping net neutrality as well... So lets stop here, wait for a year and come back to this thread and talk what happened - maybe i am totally wrong, maybe i am not. We will see.
  4. C++ Win32 Clang c++98 vs c++11

    Never mind, i am back to C++/11 and will never go back to older standards. I dont want to add dozens of lines just for detecting the proper size of things. Also i dropped the custom integral types and just include stdint.h and stddef.h.
  5. C++ Win32 Clang c++98 vs c++11

    Is this better? // // Limits & Types // #include <limits.h> #define FPL_MAX_U8 UCHAR_MAX #define FPL_MIN_S8 SCHAR_MIN #define FPL_MAX_S8 SCHAR_MAX #define FPL_MAX_U16 USHRT_MAX #define FPL_MIN_S16 SHRT_MIN #define FPL_MAX_S16 SHRT_MAX typedef unsigned char fpl_u8; typedef unsigned short fpl_u16; typedef signed char fpl_s8; typedef signed short fpl_s16; #if LONG_MAX == 9223372036854775807 // 64-Bit Platform # define FPL_IS_LONG64 # define FPL_POINTER_SIZE 8 # define FPL_MIN_S32 INT_MIN # define FPL_MAX_S32 INT_MAX # define FPL_MAX_U32 UINT_MAX # define FPL_MIN_S64 LONG_MIN # define FPL_MAX_S64 LONG_MAX # define FPL_MAX_U64 ULONG_MAX typedef signed int fpl_s32; typedef unsigned int fpl_u32; typedef signed long fpl_s64; typedef unsigned long fpl_u64; #else # if defined(FPL_ARCH_X64) # define FPL_POINTER_SIZE 8 # else # define FPL_POINTER_SIZE 4 # endif # if INT_MAX == 2147483647 // X86 or X64 Platform # define FPL_MIN_S32 INT_MIN # define FPL_MAX_S32 INT_MAX # define FPL_MAX_U32 UINT_MAX typedef signed int fpl_s32; typedef unsigned int fpl_u32; # define FPL_MIN_S64 LLONG_MIN # define FPL_MAX_S64 LLONG_MAX # define FPL_MAX_U64 ULONG_MAX typedef signed long long fpl_s64; typedef unsigned long long fpl_u64; # else // Unknown Platform # define FPL_MIN_S32 LONG_MIN # define FPL_MAX_S32 LONG_MAX # define FPL_MAX_U32 ULONG_MAX typedef signed long fpl_s32; typedef unsigned long fpl_u32; // @TODO(final): Not sure if LLONG is right here # define FPL_MIN_S64 LLONG_MIN # define FPL_MAX_S64 LLONG_MAX # define FPL_MAX_U64 ULONG_MAX typedef signed long long fpl_s64; typedef unsigned long long fpl_u64; # endif #endif #if FPL_POINTER_SIZE == 8 typedef fpl_s64 fpl_sptr; typedef fpl_u64 fpl_uptr; #else typedef fpl_s32 fpl_sptr; typedef fpl_u32 fpl_uptr; #endif #if defined(FPL_ARCH_X64) || defined(FPL_IS_LONG64) typedef fpl_u64 fpl_size; #else typedef fpl_u32 fpl_size; #endif
  6. C++ Win32 Clang c++98 vs c++11

    Okay that helps. Thanks.
  7. C++ Win32 Clang c++98 vs c++11

    Yeah until you need LLONG -> long long, 64 bit integer - then you are up in C99 or C++/11 space. So what should i do? Include the limits and match the size of all the macros on my types? Regarding the constexpr include: Even microsoft itself cannot detect properly C++/11, you cannot turn C++/11 off in visual studio 2017+, but in clang its correct set to, except for _MSC_VER, this is set to 1900, because it uses the visual studio includes magically. #if _MSC_VER >= 1900 #define _ENUM_FLAG_CONSTEXPR constexpr #else #define _ENUM_FLAG_CONSTEXPR #endif #define DEFINE_ENUM_FLAG_OPERATORS(ENUMTYPE) \ extern "C++" { \ inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator | (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) | ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ inline ENUMTYPE &operator |= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) |= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator & (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) & ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ inline ENUMTYPE &operator &= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) &= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator ~ (ENUMTYPE a) throw() { return ENUMTYPE(~((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a)); } \ inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator ^ (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) ^ ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ inline ENUMTYPE &operator ^= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) ^= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ } #else #define DEFINE_ENUM_FLAG_OPERATORS(ENUMTYPE) // NOP, C allows these operators. #endif Speechless, but wells its that what i was expecting... more or less.
  8. C++ Win32 Clang c++98 vs c++11

    Good idea, i will look into that. No idea why i didnt thought this solution myself... I know, but there are no "default" types in C++/98, so i have no choice to define them myself. But really the only problem i see are unsigned int64 aka long long and the dilemma about long vs int. Maybe short can be defined in a weird way, but i wouldn´t expect that "int" is less than 32-bit or "char" more than 8-bit. Unfortunatly i dont have platforms which are defined other than that and right know, i support x86 and x86_64. But i will ask a friend which works all day on dozens of different platforms.
  9. C++ Win32 Clang c++98 vs c++11

    I still cannot get it to compile with clang, even after i cleaned up all c++/98 incompatible stuff and now get the following error: In file included from FPL_Console\main.cpp:13: In file included from ..\final_platform_layer.hpp:2966: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\Windows.h:168: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\shared\windef.h:24: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\shared\minwindef.h:182: C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\winnt.h:11483:1: error: unknown type name 'constexpr' DEFINE_ENUM_FLAG_OPERATORS(JOB_OBJECT_NET_RATE_CONTROL_FLAGS) C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\winnt.h:11483:1: error: expected ';' after top level declarator C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um\winnt.h:2288:38: note: expanded from macro 'DEFINE_ENUM_FLAG_OPERATORS' inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator | (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) | ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \ The line 2966 in my library is just the include of the windows.h -.- I have no idea why clang in combination with the windows header wants to use constexpr... Here are the clang input: clang -g -Weverything %IGNORED_WARNINGS% -DFPL_DEBUG -std=c++98 -O0 -I..\ -lkernel32.lib -o%BUILD_DIR%\FPL_Console.exe FPL_Console\main.cpp > error.txt 2>&1 If you want to try it yourself: - Clone https://github.com/f1nalspace/final_game_tech - Go into demos folder - Call "clang_x64_debug.bat" - Look into the errors.txt Does LLVM/clang not support c++/98?
  10. C++ Win32 Clang c++98 vs c++11

    I dont intent to use any libraries whatsoever in the library itself - except for very raw operating system libraries, like kernel32.dll in win32 and libld.so in linux. Also if possible i would eliminate the need of the c++ runtime as well. Therefore thirdparty libraries are out of question! But i know that you cannot get it work on every platform/architecture - i just want to work it for common combinations like MSVC/Win32 or Clang/Win32 or Clang/Posix or G++/Posix in x86 and x86_64.
  11. C++ Win32 Clang c++98 vs c++11

    Seems like this is the way to go: // // C++ feature detection // #if (__cplusplus >= 201103L) || (defined(FPL_COMPILER_MSVC) && _MSC_VER >= 1900) # define FPL_CPP_2011 #endif #if !defined(cxx_constexpr) # define cxx_constexpr 2235 #endif #if !defined(cxx_nullptr) # define cxx_nullptr 2431 #endif #if !defined(__has_feature) # if defined(FPL_CPP_2011) # define __has_feature(x) (((x == cxx_constexpr) || (x == cxx_nullptr)) ? 1 : 0) # else # define __has_feature(x) 0 # endif #endif #define FPL_CPP_CONSTEXPR __has_feature(cxx_constexpr) #define FPL_CPP_NULLPTR __has_feature(cxx_nullptr)
  12. C++ Win32 Clang c++98 vs c++11

    Well i have written a platform abstraction library and i want this to be as portable as possible, so its based on C++/98 - but i want to optionally want to support C++/11 features like constexpr, nullptr and the standard types. So the only thing i want right know is to reliably detect if i am compiling with C++/11 or not - on common platforms (Win32, Linux, Unix) and compilers (MSVC, G++, CLANG, Intel, MingW). But thanks for that infos!
  13. I am having trouble getting clang into a C++/98 mode, can someone help me with that? 1.) No uint32_t in c++/98 // Are this the correct includes for uint32_t and size_t ? #include <stdint.h> // uint64_t, uint32_t, uint8_t, int16_t, etc. #include <stdlib.h> // size_t #include <limits.h> // UINT32_MAX /* ..\final_platform_layer.hpp:1646:11: error: unknown type name 'uint32_t'; did you mean 'int32_t'? fpl_api uint32_t ReadFileBlock32(const FileHandle &fileHandle, const uint32_t sizeToRead, void *targetBuffer, const uint32_t maxTargetBufferSize); */ 2.) Macro is expanded always - even though __cplusplus should not be greater than 199711... #if (__cplusplus >= 201103L) || (_MSC_VER >= 1900) //! Null pointer (nullptr) # define fpl_null nullptr //! Constant (constexpr) # define fpl_constant constexpr #else //! Null pointer (0) # define fpl_null 0 //! Constant (static const) # define fpl_constant static const #endif /* In file included from FPL_Console\main.cpp:13: ..\final_platform_layer.hpp:1623:4: error: unknown type name 'constexpr' fpl_constant uint32_t MAX_FILEENTRY_PATH_LENGTH = 1024; */ I am compiling like this (Win32): set BUILD_DIR=bin\FPL_Console\x64-Debug set IGNORED_WARNINGS=-Wno-missing-field-initializers -Wno-sign-conversion -Wno-cast-qual -Wno-unused-parameter -Wno-format-nonliteral -Wno-old-style-cast -Wno-header-hygiene rmdir /s /q %BUILD_DIR% mkdir %BUILD_DIR% clang -g -Weverything %IGNORED_WARNINGS% -DFPL_DEBUG -std=c++98 -O0 -I..\ -lkernel32.lib -o%BUILD_DIR%\FPL_Console.exe FPL_Console\main.cpp > error.txt 2>&1
  14. what is the appeal of fps games?

    For me old fps will always have a place in my gamer heart, as i was growing up with local area network multiplayer games like Doom, Quake, Duke Nukem, Unreal etc. At that time i had a lot of fun playing these fps with friends in closed dark rooms, side by side, with the pc´s heating up the room like crazy, eating pizza, etc. Really it was fun and i really miss it. Unfortunatly todays fps games and gamers are totally different, they just want as violant, as realistic as possible, as close to war as possible, just because its "hip" or something. I personally dont like this kind of games, because there so much real war going on in our world, so why bringing that in the virtual world? - whats the point, what is the fun? I dont see it, and i will most likely not understand that. But well generations are different, so i have to bear with the fact with that 10 year old childrens play adult fps war games and talk like it was pokemon or something. I rather jump around in virtual worlds, doing insane movements and jumps, getting as fast/high as possible. I enjoy it much more using weapons as a tool to reach impossible ledges, instead of using it to shoot others. The reason why i played the "Defrag"-Trickjumping mod from Quake 3 Arena over 10 years. But nowadays i dont play any fps games anymore because of several reasons: - I hate any kind of close to war fps - Too much online multiplayer going on - Modern fps are no fun for me, especially the COD and BF series - I dont have much time anymore, i spent these more wisely - My eyes cannot handle it anymore, i am getting old Everyone has their own story why they like or dont like fps games - so we only can share our personal experience with playing fps and why it may be fun or not. For me that time i played such games are long over and enjoy other game types much more.
  15. Milestone Update! I finally finished a huge milestone -> Audio playback! Hurray! Also i extended the api a little bit and fixed some major bugs. Now i can really start to focus on the next platform -> Linux X11/GLX/ALSA. In addition i added a FFMPEG demo for testing out several features of the library, especially the multithreading and the audio system. At its current state the demo can already decode/render audio and video independently, including some caching of raw packets and decoded data. Works great, even though the ffmpeg api is a nightmare. My main focus is get the ffmpeg to a usable state and then continue implementing the linux platform. Also i decided to change the library a bit to not require C++/11 at all. Enum class and constexpr is nice, but there is no real reason to use that. So the next version will be C++/98 complaint. See the full changelog for details. Last important note: The asyncronous audio playback system is a stripped port from "mini_al.h" -> A awesome single header file library written by David Reid. So if you need more audio features than fpl provides, i recommend using "mini_al.h" directly. Here is the full changelists: ## v0.5.1 beta: - New: audio::GetAudioNativeFormat() - New: audio::SetAudioClientReadCallback() - Fixed: InitFlags::Audio was never tested before InitAudio() was being called. - Changed: Renamed ThreadStop to ThreadDestroy ## v0.5.0 beta: - Added: [Win32] DirectSound playback support - Added: Asyncronous audio playback ## v0.4.11 alpha: - Fixed: [Win32] For now, load all user32 functions always, even when window is not used (This is to prepare for audio playback) - Fixed: [Win32] ThreadStop was not releasing the thread handle - Added: [Win32] ThreadWaitForAny - Added: [Win32] SignalWaitForAll - Added: [Win32] SignalWaitForAny - Added: [Win32] SignalReset - Added: FPL_NO_VIDEO - Changed: ThreadWaitForSingle renamed to ThreadWaitForOne - Changed: ThreadWaitForMultiple renamed to ThreadWaitForAll - Changed: SignalWait renamed to SignalWaitForOne ## v0.4.10 alpha: - Removed: Removed all _internal _INTERNAL postfixes from types, functions and macros - Changed: Proper identitation for compiler directives based on context - Added: [Win32] Dynamically loading ole32 functions (CoCreateInstance, CoInitializeEx, etc.) - Fixed: [Win32] GetCursor was not using the dynamic loaded function - Fixed: [Win32] Missing *Clipboard* dynamic functions ## v0.4.9 alpha: - Removed: Removed all audio code for now - Changed: A total cleanup of all internal stuff, so its much easier to add in new features ## v0.4.8 alpha: - New: AtomicLoadU32, AtomicLoadU64, AtomicLoadS32, AtomicLoadS64, AtomicLoadPtr - New: AtomicStoreU32, AtomicStoreU64, AtomicStoreS32, AtomicStoreS64, AtomicStorePtr - New: AtomicExchangePtr, AtomicCompareAndExchangePtr, IsAtomicCompareAndExchangePtr - New: [Win32] Implementation for AtomicLoadU32, AtomicLoadU64, AtomicLoadS32, AtomicLoadS64, AtomicLoadPtr - New: [Win32] Implementation for AtomicStoreU32, AtomicStoreU64, AtomicStoreS32, AtomicStoreS64, AtomicStorePtr - New: [Linux] Implementation for AtomicLoadU32, AtomicLoadU64, AtomicLoadS32, AtomicLoadS64, AtomicLoadPtr - New: [Linux] Implementation for AtomicStoreU32, AtomicStoreU64, AtomicStoreS32, AtomicStoreS64, AtomicStorePtr - New: [Win32] Loading of DirectSound (Prepare for audio output support) - Draft: Added first audio output api - Fixed: Threading context determination - Fixed: [Win32] Fixed all thread implementations - Fixed: [Win32] SetWindowLongPtrA does not exists on X86 - Fixed: [Win32] Missing call convention in SHGetFolderPathA and SHGetFolderPathW - Changed: Improved header documentation (More examples, better descriptions, proper markdown syntax, etc.) - Changed: All threading functions uses pointer instead of reference - Changed: [Linux] Atomic* uses __sync instead of __atomic - Changed: A bit of internal cleanup