next »

[Crimsontide]

If that's all you want, why not write a C parser?  You can download the grammar pretty much anywhere, add simple operator overloading, and voila the perfect language?

https://www.lysator.liu.se/c/ANSI-C-grammar-l.html
https://www.lysator.liu.se/c/ANSI-C-grammar-y.html

[qMopey]

Problems with parser: A) I’d rather write a game than a language tool; B) adds another build step to the build process; C) new devs coming onboard hit a learning curve; D) makes the output much more difficult to use a debugger on.

There are more problems too, but these are the big ones off the top of my head.

So yes writing a tool that outputs C would work great. But it needs a debugger and it needs a lot of documentation, and it needs continual maintenance. Generally these are the pieces lamguage creators miss, because they are only interested in useless but novel things, rather than pragmatic things with utility.

[Crimsontide]

After over a weeks worth of debugging, I finally the issue.  I missed a bracket...

The whole compiler basically died giving me all sorts of nonsensical errors.  Would eventually compile and then fail on the linkage stage saying functions that existed didn't.  Moving code around (but not changing it) would cause parts to work but others to fail.  Intellistupid completely failed crashing repeatedly.  All because I missed a bracket???

Come on MS... this is unacceptable.

[fluffrabbit]

I've spent the last 6 months trying to unproject a planar world for mouse picking. Most recently I've tried ray-plane intersection. But I don't get it. At all. It's causing a lot of stress.

EDIT: Looks like somebody else is having the same problem at this very moment.

EDIT 2: I just solved it 30 seconds ago. 6 months of working on the same function, the last 48 hours of which involved deep thought, loud music, and the rabid clicking of links. I must have read 20 different articles on how to do ray-plane intersection, which taught me the difference between different kinds of vector multiplication: elementwise, cross product, and dot product. This is math that is specific to computer science as it's considered too complicated to perform by hand, though my intersect function is only about 50 lines and could probably be simplified to 30 while still being readable.

The devil is in the details. The theory behind turning a screen pixel into a unit vector is solid. The theory behind intersecting a vector with a plane is solid. The trick is in adapting the theories to your renderer. There's Z-forwards Y-up DirectX, Z-backwards Y-up OpenGL, Y-down Vulkan, and 2.5D coordinate spaces which are often unique from all of the above. I have to multiply by -1 constantly due to the dyslexic back-and-forth of screen pixels VS OpenGL clip space VS 3D world space VS imaginary grid space. My engine is extremely abstracted.

[BorisTheBrave]

@fluffrabit - while you are learning about vector operations, you might want to read up on matrices too.

The reason i mention it is because matrices encapsulate a lot of different transformations. Once your engine makes a modelViewProjection matrix used for rendering, the same matrix can be inverted to instantly find the conversion from screen pixels back to a ray in world space. That saves a lot of faff with conventions as you only need ensure you've got the renderer correct.

[fluffrabbit]

@fluffrabit - while you are learning about vector operations, you might want to read up on matrices too.

The reason i mention it is because matrices encapsulate a lot of different transformations. Once your engine makes a modelViewProjection matrix used for rendering, the same matrix can be inverted to instantly find the conversion from screen pixels back to a ray in world space. That saves a lot of faff with conventions as you only need ensure you've got the renderer correct.

So I can do inverse( mvp ) * cursorClip to get the ray? That's a smart optimization. I actually felt like I was more confident with matrices than vectors, but this black box stuff like inverse and transpose and the order in which you put things and how you combine things, and the elementwise matrix multiplication... So much stuff, it's not enough to just know which part of the matrix does what. I am definitely going to follow your advice, thanks.

[ThemsAllTook]

Now that I have Core Audio doing what I want, I've moved on to DirectSound. API documentation for it is slightly better, but still leaves a lot to the imagination. I had a mysterious bug for a while where a function that had no reason to block was never returning once I called it, which turned out to be caused by a simple buffer overrun. I'm able to get the speakers to make noise now, but it's kind of mangled, and sounds different every time I run my test program. There are a lot of tweaks I can make to buffer sizes and latency to try to get it to behave better, but so far I haven't found the magical values that smooth it all out.

...oh. While writing this post, I think I realized the problem. Complaining was useful! If the problem was what I think it was, it's pretty complicated to explain, so I'll report back later when I know whether I'm on the right track or not.

Really ready to be done with audio APIs at this point.

[qMopey]

Same story if you need directsound reference, cute_sound can be used as a reference.

[ThemsAllTook]

I've been using both portaudio and cute_sound as references, but they never map 1:1 with how my code needs to work, and are also different from each other. The puzzle is to put together the pieces I actually need from API documentation and the two references, and to figure out why my code doesn't work when it looks like it's doing functionally the same thing as the working references.

[qMopey]

Oh yes that does sound like a recipe for grumpy. Hopefully you can sort your implementation out soon enough! I learned most of my directsound stuff from handmade hero. Something like episode 13 or something very early on. IMO his video is the best docs on DirectSound, at least that I could find.

[ThemsAllTook]

Phew. OK, my hunch was right. DirectSound is all working now. The problem I was having above had to do with improper write cursor management. I'll do my best to explain in case anyone stumbles into this thread later with the same problem...

The basic principle of the API I'm implementing is that after initialization, the application using it will tell the audio system to start outputting to the speakers, providing a data provider callback function which an audio thread will call repeatedly to fetch data. In the DirectSound implementation, I create a buffer and call IDirectSoundBuffer_Lock on it to retrieve a pointer I can write to. What I had been doing was to pass the DSBLOCK_FROMWRITECURSOR in its flags, so that Lock would give me a write location at the end of the data I'd already written.

Problem is, I was calling this pretty much as fast as possible (with a few-millisecond Sleep invocation in between cycles), so it was consuming data way too quickly with no timing control. I had to switch to using IDirectSoundBuffer_GetCurrentPosition to query the buffer's readiness to receive additional data. If it returned the same value twice in a row because I was calling it too fast, I'd do nothing, call Sleep, and try again in a few milliseconds. If it was ready for data, I needed to do the appropriate math on the returned write cursor position to only fill it with enough data to stay ahead by my chosen latency value.

This was surprisingly hard to get right. I was sure I had left it in a broken state, walked away to do something else, but after I came back...it all worked somehow? All of my test cases are passing, so I guess it's in good shape. Phew. Still going to need to do something for Linux/Android at some point, but having working sound on Mac and Windows will get me pretty far. Going to set this down so I can do something less unpleasant for a while.

[qMopey]

If you’re using SDL they have Linux and android support. They expose a circular buffer callback and more or less give you direct access to the underlying driver. Might be a good option for those platforms.

[gimymblert]

Jonathan Blow - Preventing the Collapse of Civilization (English only)


It's clickbaity title that makes sense in context and is not so clickbaity.
It parallel some observation I had having and kinda feed my confirmation bias.

The only thing with that talk is that I'm thinking, "same but for hardware", mostly because I realized I can't print my own chip and going down the process of learning about that.

[J-Snake]

Nice talk. But a solution to the problem would require a quality over quantity approach. I am personally all for it. But let's face the reality. The demand for software is larger than ever before, and most software is not mission-critical. But the amount of experts or competent people remains relatively small, that is a constant throughout the human history (Even though we have resources like the internet today which can greatly accelerate education, we all know that too many people use it for shallow entertainment and to dumb oneself down). From that it follows that there has to be a large amount of incompetent people working on software. And regarding the games industry, for example, tools like Unity enable those people to be productive. Even though these tools operate on unnecessary complexity, they still enable less competent people to get a variety of bigger projects done. Before tools like Unity, you wouldn't see that many games with larger production values and scopes. Sure, most games aren't perfect, but many still achieve a scope and production value to find an audience to enjoy them.

[gimymblert]

To be frank, this talk should only concern the core backbone of the infrastructure, not the peripheral activities.

When he talk about loss of knowledge and people doing whatever, I think he overgeneralized.

HOWEVER, now we are seeing permeability between the two, where major infrastructural work are made by local bakery growing too fast and become institution (facebook).

Funnily Unity use to be one of those, it's one of the infrastructural node,  the transition to something better from a local bakery is what cause them the current pain (with ECS) but they also pay attention to actually diffuse the infrastructural knowledge (said ECS framework come with knowledge passing structure, like the profiler showing you the compiled assembly, and  tutorial expressly mentioned end explained memory structure and layout.

I'm more worried on that unity is itself based on hardware infrastructure that has been set by tradition (see all the setbacks of the CISC x86 architecture at intel with teh various point of failure) but then we still has a great push of the alternative with RISC on mobile. On the other hand we have a HUGE fragmentation on that side, where the complexity has been moved to form factor, where one size does not fit all, and create point of failure.

And that is why I think hardware is a big(g)ger concern, you can't print your own chip, that is chip making knowledge, unlike software that are based on it, is very concentrated and obscured by corporate secrets. It's a huge point of failure, if one fold, that's a lot of knowledge loss, and it default to software based on it, that is if the hardware failed, you can't access the knowledge encoded for it.

So while at my scale (at least right now) it's foolish endeavor, I keep tab of way to make my own chip by principle.

Also the fact that economical pressure kind of kill experimentation in that field (see the ps3 cells, whatever their true success where). The mobile open the opportunity for new way of thinking that has lead to a reversal of intel amd struggle for example, that is while the x86 evolution had many failures recently, we didn't universally relied on it and had alternative that make the infrastructure resilient to a single point of failure (also the risc arm evolved to be competitive by being sheltered in its own niche), but apparently we do have already loss a lot of knowledge.

In the end the nuance way of doing it is that we kinda need both tendencies to avoid collapse, single point of failure with enforced best practices are not great to resist unforeseen events (like with intel's), but until that event stability is really great due to great synchrony. However fragmentation is needed to add diversity which bring resilience to unforseen events (like with amd's and arm's) but too much fragmentation create chaos and disconnection, complexity create loss of knowledge because you can't hold all the knowledge of a fragmented ecosystem, the cost is just too high.

I feel like hardware now is the biggest risk than software, especially in the face to the pressure to centralized into costly datacenter. If a center fail, all the software and documents (knowledge) dependent on it fails. That's like a huge infrastructure problem. And it had already happen multiple time.

[Daid]

Grumble grumble. Trying to make my game engine work on Android. Build on top of SDL2, which has Android support.

One thing they forgot to mention is your main() function can be run multiple times. Without re-initialing memory and stuff, so any global/singleton you set is still there.
Odd thing is, I see the 2nd run of main() before I even see the first run properly returning...

[oahda]

I actually had that happen to me just the other day (also SDL2 on Android), but it turned out to be due to other issues with the game causing it to crash and then the phone attempted to start it again, so once I fixed the crash, it fixed that. Or so I thought, until now? :E Under what circumstances is it happening to you? I even tried opening lots of other apps to see if something like high memory usage would cause it to happen once I swapped back to my app again but I never managed to make it happen again after that…

[Daid]

Well, found out I wasn't handling the SDL_QUIT event, that cause my first run of main to never exit. My S3 is a bit of an old phone, so maybe that's related as well.
https://developer.android.com/guide/components/activities/activity-lifecycle
I think it happens if the activity goes trough onStop and then to onRestart. I found a post on the SDL mailing list as well that this was expected behavior...

Now I just need to figure out why my OpenGL window has a different actual rendering size then SDL is reporting. Just applied the hack that I get the values from glGetInteger(GL_VIEWPORT) to get the rendering size instead of requesting it proper from SDL.

[oahda]

I wrote this way too long ago now to remember the specifics of it or how I learned about it, but I do have some special Android-specific code to get the dimensions after window creation in case it helps:

Code:

SDL_Rect rect;
SDL_GetDisplayBounds(0, &rect);

And then just rect.w and rect.h. Maybe the difference was that this accounts for the size of the bar with the Android software buttons or something?

In case you need that too, I also have this specific to iOS:

Code:

CGRect rect = [[UIScreen mainScreen] bounds];

With rect.size.width and so on, optionally multiplied by [UIScreen mainScreen].scale to account for retina.
                        

[Daid]

Problem is, with SDL 2.0.9 (didn't check latest master yet) all functions, SDL_GetDisplayBounds, SDL_GetWindowSize, SDL_GetCurrentDisplayMode, SDL_GetDisplayUsableBounds, SDL_GetWindowSurface()->w/h report "720x1280".
I'm rendering with OpenGL ES, and the positioning of my rendering was off when I use glViewport.

SDL is also reporting (in logcat)

Code:

V/SDL     (27931): Window size: 640x1138
V/SDL     (27931): Device size: 720x1280

Of which the "Window size" seems to be the size of the OpenGL buffer that I'm getting to render on, but no way to get it from C or influence it properly so it matches the device size...