next »

[kverkagambo]

Nice, but the way the cards overlap together with the military theme makes my brain see swaztikas, which might be a bit unfortunate (or theme-appropriate perhaps, depending on what game that is).

Interesting, I never thought about it like that. 
But no, there are no swastikas and don't believe many people will find them there. Just cards.

[Dacke]

I'm with Prinsessa, I've tried to see them multiple times but can't find 'em.

[ProgramGamer]

Are you referring to the grid of cards on the right? If so, your swastikas are a really far stretch.

[kverkagambo]

Historical period of the game is the year 1919, right after the World War One. Swastika became a widely used symbol of evil many years later.

[ProgramGamer]

I just found a C++ project on my computer that dates back to September. It runs on SDL2, has game states and uses the surface pro's touch screen as input. I barely remember programming such a thing. what the heck.

[Cheezmeister]

I see your September and raise you one decade (see devlog) It runs on SDL1.2, has memory leaks and uses ints in a text file for levels.

But here's the happy: It's surprisingly refreshing to return to the first game I ever wrote. Just reading through it (and playing) I'm picking up echoes of the raw joy and passion that have eroded since I started getting paid to program.

<3

[oahda]

Wooh! I had had a thing creeping up on me for a while and it was about time I fixed it, so like yesterday or the day before or whatever I started fixing this.

The issue was that I'd gone and done quite the blunder when it came to vectors in my engine, which I'd added some 2+ years ago when first working on the engine. I didn't know too much linear algebra back then, so it never really became an annoyance until much more lately. I had two classes, Point and Vector, for 2D and 3D respectively, showing that I had the terms a bit confused at the time. The latter inherited the former class and added the z component.

There were some issues with how they interacted, but more importantly, all over the codebase, I'd kind of been treating Vector like a 2D one anyway. So the normalisation function I had implemented ignored z, for example. Lots of little things like that.

Not a biggie if I'm to work on a 2D game, but it doesn't exactly make for a good-looking engine and since I might make 3D games with it in the future and even am considering some 3D stuff for this game, it just... needed to be dealt with, before it was too late to make the changes, on an enormous codebase.

The codebase was still big, however. After replacing Vector and Point with one new vector class, with the number of components a template value, to which I added a bunch of handy stuff I learned to love from GLSL, like swizzling, and virtually every possible syntax for modifying the values and operating on the vectors, I started the long process of working my way through all of my files to fix them up to use the new class.

It wasn't just a matter of search and replace, in part since I had to replace both Point and Vector, and also since I hadn't consistently been using them anyway, and some of the instances of Vector were actually supposed to be replaced with 2D vectors. I also updated many of the expressions along the way to use a lot more elegant and concise syntax thanks to the great care I'd given to writing the new class.

Hours upon hours. Took a long time. But once it finally compiled with zero errors... absolutely nothing had changed. No bugs, nothing. That sure is the best feeling in the world! It's always incredibly scary to make enormous refactors like these.

So worth it! Future problems prevented at a reasonably early stage, and working with vectors from now on will be so much nicer.

[zilluss]

I had two classes, Point and Vector, for 2D and 3D respectively, showing that I had the terms a bit confused at the time. The latter inherited the former class and added the z component.

I recently looked how Unity does things with Vector3/Vector2. Vector3 can't inherit from Vector2 since they are structs and in C# structs don't feature inheritance. But it got me thinking if it makes sense for Vector3 to inherit at all.
Semantically an inherited class is a specilazation. But a 3D vector is not a specialization of a 2D vector and should therefore not be a subclass. It's similar to the ellipse-circle problem (https://en.wikipedia.org/wiki/Circle-ellipse_problem).
Forcing explicit casts from Vec3 to Vec2 (via swizzle operators) also clarifies the intent, which is a huge plus.

[InfiniteStateMachine]

Codebases that attempt to share any part of vector2 and vector3 via inheritance, templating or whatever are always very suspect to me. It's a big sign of overengineering.

Both of those structs should be exactly that. Simple structs (or classes if you like member functions) with no inheritance or generated code.

[gimymblert]

Vector can have n dimensions, it's useful to generalize, what if you don't other operation like measuring distance between data sample?

[InfiniteStateMachine]

Vector can have n dimensions, it's useful to generalize, what if you don't other operation like measuring distance between data sample?

Vector2 and Vector3 in the context of games are my arguments specifically. Besides the overkill factor I previously described there's a performance issue that occurs both from both indirection and generated code size (i-cache optimization).

If you are doing numerical analysis on lots of n-dimensional vectors that's a different argument where these methods could certainly be valid.

[oahda]

There's no difference in performance. They're still super basic at their core and hold no more variables than their components. Definitely negligible to the point where I care more about my convenience as a programmer using the library.

Not much to discuss or defend, really. Just a matter of personal preference IMO. There are so many ways to use C++ and everybody disagrees. I do what works for me and my purposes.

The point of my message was just: yay, I updated the entire codebase to use this new class and I didn't break anything! \0/

But a 3D vector is not a specialization of a 2D vector and should therefore not be a subclass.

Yeah. Feels a lot better now.

Forcing explicit casts from Vec3 to Vec2 (via swizzle operators) also clarifies the intent, which is a huge plus.

Yeah, it's a little half-half for me now. A global function like distance(v1, v2) of course requires swizzling if I have two 3D vectors but I just want to get the distance between their x and y values and ignore z.

But I can set a 2D vector from a 3D vector, which just discards the z component, because I think that makes perfect sense and is always clear enough. There are a few engine reasons for this, like game objects always storing their translation in 3D, but if you're working on a 2D game it just gets annoying to have to explicitly swizzle xy all the time when it's obvious that that's what you want virtually everywhere. Likewise if you want to update an object's translation from a 2D vector resulting from one of your calculations.

It's tailored to the particular use cases of my engine I've had a long time to figure out now, simply.

[InfiniteStateMachine]

EditEdit: If my post came off as abrasive I apologize. I was replying to Ziluss's post before reading yours. I wasn't specifically calling out your implementation. Re-reading my post after reading yours in context makes me look like a matter of fact jerk  

There is potential for performance issues when using the template method. It's not an issue of holding more members, it's an issue of generating more assembly instructions than necessary. Mainly because if the generated code generates more assembly (which you COULD theoretically avoid but it's way harder to do with code gen to the point it's not worth it) it will cause more instruction cache misses. For a struct used constantly at a low level this adds up.

There's also the performance issue in regards to compile time. That's completely unavoidable by virtue that the templating engine is invoked.

EDIT : Of course if you don't care about perf to that degree you could easily argue against the first point. From a usability point of view I still find non-templated structures easier to use though. That's a personal preference though (albeit I don't find it to be an esoteric preference).

Also congrats :D

[oahda]

Now that's confusing!

Well, your facts are completely correct, of course. I just mean that the issues don't exist in practice for my use case.

As for compile time, I've learned enough tricks over the years, like predeclaration. Doing a clean build of the entire engine and game, including a few libraries that I compile directly into the engine, like AngelScript, still takes probably less than a minute, and obviously I don't do clean builds most of the time anyway, so it's working out so far. c:

[InfiniteStateMachine]

Ah yeah I forgot you had an angelscript layer too. I suppose if you are doing most of your gameplay logic in there then the compile time issue probably doesn't matter too much either. Regardless, under a minute is very good.

[oahda]

Yeah, I really started noticing lately when adding some creature AI that was entirely scripted and I didn't have to recompile at all while updating the code countless times. So handy!

Tried clocking some clean builds just for the sake of it, and it seems to be slightly dependent on what Xcode/LLVM feels like. Took 70 seconds one time and 35 seconds another. But on average, about a minute, I guess. Remembered I'm also compiling Box2D and SoLoud into the engine (I still compile them, as well as AS, to separate targets which I link the engine to, tho, so I could still do a clean build of the engine itself without necessarily recompiling those dependencies).

[InfiniteStateMachine]

I've noticed that with clang/llvm too. Sometimes a warm recompile will suddenly take longer than I would have expected. Not sure exactly what I'm doing that's causing this. The same warm compile doesn't have the same effect on other compilers I tried too. I currently have no idea why that happens.

[oahda]

Yeah, a related issue is that it always takes a long time to boot the game from Xcode when I haven't touched it in a couple of hours, but is almost instantaneous while I'm actively working on it and recompiling and rebooting it often. I wonder if it's debugger stuff that's left in RAM for a while or something.

[BorisTheBrave]

The OS caches recently accessed files. So any background process that touches disk or uses ram can cause evictions, making your warn recompile code.

Compiling is particularly affected as many build systems will load the metadata for every file in the project, to determine what has changed.

Having an SSD is recommended for development work.

[zilluss]

EDIT : Of course if you don't care about perf to that degree you could easily argue against the first point. From a usability point of view I still find non-templated structures easier to use though. That's a personal preference though (albeit I don't find it to be an esoteric preference).

Given the raw processing power we now have available I tend to ignore performance for my considerations, unless I target low-powered devices or I were to create a high-end game. AFAIK, the 3 rules of optimization are: 1) Don't 2) not now 3) measure. I often forget about this though

My reply was about proper OOP. If you work with several people (and I count my past self as a different person) I think it's important to properly communicate your intent without resorting to comments. It's basically performance optimization, but on the dev side. A clean build may take 5 minutes, but figuring out what the hell the code does I wrote a year ago takes longer.
Also, I think templated types are totally fine as long as you declare proper types that can be swapped out with a non-templated version (keeping the fact that the type is templated an implementation detail).