Layl
|
|
« Reply #5020 on: November 27, 2015, 04:45:02 PM » |
|
llvm[4]: Compiling WebAssemblyFrameLowering.cpp for Release build In file included from C:/users/layl/desktop/rust/src/llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.cpp:21:0: C:/users/layl/desktop/rust/src/llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.h:42:8: error: 'void llvm::WebAssemblyFrameLowering::processFunctionBeforeCalleeSavedScan(llvm::MachineFunction&, llvm::RegScavenger*) const' marked 'override', but does not override void processFunctionBeforeCalleeSavedScan(MachineFunction &MF, ^
oh.................
|
|
|
Logged
|
|
|
|
Canned Turkey
Guest
|
|
« Reply #5021 on: November 27, 2015, 07:19:28 PM » |
|
I ended up going overboard (as I tend to do) and made it basically emulate the Unity UI
Yeah or just do that
|
|
|
Logged
|
|
|
|
|
Dacke
|
|
« Reply #5023 on: December 01, 2015, 11:49:20 PM » |
|
haha, cute
|
|
|
Logged
|
programming • free software animal liberation • veganism anarcho-communism • intersectionality • feminism
|
|
|
gimymblert
|
|
« Reply #5024 on: December 02, 2015, 01:12:02 PM » |
|
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5025 on: December 02, 2015, 02:59:46 PM » |
|
Yeah I use c++ the majority of the time but I very rarely use STL except sometimes in personal projects. It's not a great API but when you consider it's general scope and the time it was initially implemented it's very impressive.
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #5026 on: December 03, 2015, 02:07:55 AM » |
|
Hasn't it been cleaned up a lot with C++11 and C++14?
I don't know much about a lot of areas of the STL tho. I mostly just use the containers and string streams.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #5027 on: December 03, 2015, 10:57:02 AM » |
|
I guess that depends on what your definition of cleaned up is. They can't give it a more modern public api since one of the goals is to not break backwards compatibility. They added std::thread and other concurrency constructs. Then again I'm used to external third party api's since I couldnt wait N years for them to finally getting around to ratifying threads.
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #5028 on: December 03, 2015, 12:15:41 PM » |
|
They did change all the existing code to support move semantics, but no one sane would describe that as a cleanup.
C++11 added shared_ptr and unique_ptr and auto, which do make a lot of C++ cleaner. But not the STL, specifically.
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #5029 on: January 24, 2016, 05:01:53 PM » |
|
Gahh. Got one of those bizarre super specific bugs. Of course it's always positive when a bug can be reproduced under identical condition, but in this case I just can't seem to figure out why that condition makes different... I have no problems rendering different stuff to different textures using different framebuffers and so on. But now, if I move the camera out of a specific area, it consistently crashes when I try to update the dimensions of a depth buffer that would gladly allow me to update it as long as the camera was in that specific position. I know for sure nothing unloads when the camera moves, but some objects do get ignored and not updated or rendered if they are out of sight. The only object that covers the general safe area that might have anything to do with rendering to texture is a light source, but the light buffer uses completely different framebuffers than the particle system that is causing the crash, and, again, as long as the general area of the light is within sight, light and particles alike work fine with no crashes... It also can't have anything to do with forgetting to unbind stuff or the like. I'm doing everything using a few utilities of the engine that make sure of this, and starting and ending this sort of stuff always happens within one frame, and there is no multithreading going on, so it can't be that, for example, the light activated something when it was visible that wasn't cleared the frame it disappeared or anything like that. And it might not even have anything to do with the light. There's also a wall mesh behind it that matches up with the safe area. I'm completely lost and this is obviously a highly personal problem so I probably can't google or forum a solution. But if someone knows any reason a call to glRenderbufferStorage might cause a crash, that could help...
|
|
|
Logged
|
|
|
|
MorleyDev
|
|
« Reply #5030 on: January 26, 2016, 11:36:19 AM » |
|
Recompiling a C++ project in Visual Studio 2015. Looks like they actually managed to break some of the SFINAE that was possible from 2013.
Sigh...one of these days Visual Studio will have good SFINAE support. Oh the template metamagic we will work on that day!
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #5031 on: January 26, 2016, 03:35:10 PM » |
|
Fixed my problem. Biggest lesson learned: when OS X says something crashed due to a "graphics error", that means that the error is in the GLSL code and I shouldn't be trying to find the error in the C++ code. Once I realised that it was in one of the shader files I found the error (infinite loop under quite specific circumstances) very soon by commenting and uncommenting code until I narrowed the problem down, took one look at the guilty code and realised what it was. Geez.
|
|
|
Logged
|
|
|
|
zilluss
Level 1
|
|
« Reply #5032 on: March 02, 2016, 11:02:37 AM » |
|
Just spent what felt like an eternity trying to figure out why SDL_GL_GetProcAddress returns some pointers invalid, leading to a segfault. Turns out if you don't forward declare a function, C guesses the return type to int which leads to a truncated pointer on when compiling for x64.
|
|
|
Logged
|
|
|
|
Sik
|
|
« Reply #5033 on: March 02, 2016, 06:10:45 PM » |
|
Which is why compilers usually warn you when you use a function without it being already declared (or defined, which has the same effect).
|
|
|
Logged
|
|
|
|
zilluss
Level 1
|
|
« Reply #5034 on: March 03, 2016, 02:55:19 AM » |
|
Which leads to my next problem, that I didn't notice I toggled that damn "hide warnings" button Thanks for the pointer!
|
|
|
Logged
|
|
|
|
shellbot
Guest
|
|
« Reply #5035 on: March 24, 2016, 11:39:27 PM » |
|
Partially grumpy and partially happy...
I just discovered python coroutines. They provide a near perfect solution to an ongoing issue I've had... If I had spent the time to read about them years ago, I could have saved countless hours developing work-arounds. I really could have applied this so many times.
God damn you past me. Bless you current me. Sorry for the inevitable over-usage future me.
|
|
|
Logged
|
|
|
|
gimymblert
|
|
« Reply #5036 on: March 25, 2016, 06:40:18 AM » |
|
I'm exciting in testing neural networks, want to apply them to polygon model, worst case, polygon soup is random order with no sequence dependence spatially or temporally, got back to my game writing that does not end but as a very simple structure,
|
|
|
Logged
|
|
|
|
Bricabrac
Level 2
Fail again. Fail better.
|
|
« Reply #5037 on: April 20, 2016, 01:58:00 PM » |
|
Spent an entire evening fiddling with different versions of rpgmaker, trying to chose the most suited for my game. Every version seem to take one step forward and two steps back. Argh!
|
|
|
Logged
|
Selling Sunlight - Wandering Merchant RPG
|
|
|
|
Zukas
Level 0
Gamer and an Indie Developer!
|
|
« Reply #5039 on: June 03, 2016, 12:28:30 AM » |
|
Been messing with RenderTextures in Unity for the past few days and there is no way to reliably test them. Same, I've spent 2 hours this night just trying to figure out what I'm doing wrong and what not.
|
|
|
Logged
|
|
|
|
|