next »

[Quarry]

SLIDING DOORS (sorry for no gif)

[nikki]

sure yeah : to each their own, and many people have differnt preferences.
my point is that it's more then possible in c#.

the operators on number(objects) '3.To()' for example is really tight and normal in languages like Python, Ruby, Smalltalk etc.

and the point thing I couldn't really understand from the c++11 example, so when I undertand what the goal is of that code  I'll show you a c# way of doing that or not

[Geti]

It's an array of objects - I named the type "PointType" to be as clear as possible (though I think his in that example is "Point". The "&" implies that the variable is a reference in C++ (and C, for that matter).
I gave you an example of the "expanded" version. Your point that "it's more than possible in C#" isn't exactly smart to make if you don't understand what the original code means/does. I wouldn't mind seeing a C# way of doing the code he says for argument's sake though. I expect it to look quite similar to your code but with a statement in there using "i" to get the object out of the array at this point.

@Quarry: 43fps seems a bit low for such chunky graphics even on the CPU, what's going on there? Expensive physics or just not bothering to optimise while it's early days? Looks fun either way.

I'm pleased cause I got some hacking in this weekend on my component based framework in Java and although the language has been fighting me the whole way, I've got a simple peer to peer (able to masquerade as client server of course, by having one peer relay all the necessary crap around) networking thing going on top of it, with some built in functionality like accepting connections, keepalive, disconnection and whatnot (requiring a password hash is on the list of things to do) as well as the ability to roll your own messages to send between states.
It's all built on top of the (now very familiar to me) Bitstream class ported from our current engine so it's able to be light on bandwidth where needed and still nice and fast sequential reads and writes.
Got to make built in Sync() functions for each of the components that needs it now plus a way of syncing the message passing system in the container entities as well of course. Been struggling to keep it data-oriented in Java so I've kinda just conceded that it's going to be nicer to program with a hybrid system.

Been missing C++ every time I do Java work recently, spend way too much time handling exceptions that aren't likely to arise and working with 5 different types to accomplish a simple task (InetAddress + port, SocketAddress, byte[], Vector<Byte> (ugh), BitStream, DatagramPacket, DatagramSocket...) when all I want to do is send a chunk of bytes to an address over UDP and handle the rest as part of the protocol.
Should've used Scala to at least alleviate one of the headaches. Might port it later if I get excited.

...This is turning kinda grumpy, haha.

Back to KAG work this week of course either way

[InfiniteStateMachine]

Got a lot of the performance issues and timing issues fixed on my vita engine done this weekend. Feels like anything I add at this point are additions and not related to optimizing performance. I may move some graphics manipulations to the GPU because the Vita is heavily in favor of the GPU.

So with that done. I actually got to work on my game this weekend lol..

[_Tommo_]

It's an array of objects - I named the type "PointType" to be as clear as possible (though I think his in that example is "Point". The "&" implies that the variable is a reference in C++ (and C, for that matter).

exactly, that was an Array<Vector>, so an array of at least 10 3D points.
The range() function is valid over any Array object independent on what it contains, so it's a bit more powerful than a thing enumerating ints

And it even works "to the end"

Code:

for( auto& obj : objects.range( 1 ) )

or in reverse

Code:

for( auto& obj : objects.range( 10, 3 ) );

the stl way of doing this is still pretty horrible and iterator heavy, too.

[nikki]

I wouldn't mind seeing a C# way of doing the code he says for argument's sake though

ok

Code:

            foreach (int i in 3.To(10))
            {
                Console.WriteLine(points[i].ToString());
            }

where points is an array of objects, in this case many int and 1 vector3

object[] points = new object[] { 1, 4, 5, 3, 2, 4, 5, 6, new Vector3((float) 2, (float) 3, (float) 4), 3, 5 };

edit : removed answer to 'not very smart' stuff
let's be happy instead

[Garthy]

my game development framework is split up into lots of tiny libraries, each with its own makefile that often has small but important differences from the template. At some point I need to do some work to get them sharing makefile code better, but I haven't figured out the right way to do it yet... The makefile is a hulking monster at nearly 1000 lines, so taking it apart and reassembling it in a more modular way isn't a small task.

Here is an option based on what I did when faced with something similar:

Write a tool (using eg. Ruby, Python, or Perl) to generate the Makefiles from a template for each file. The first pass is easy- your initial template is just the initial file, and the generator just reads the template in, line for line, and prints it out, no changes. Then, as you spot common chunks of code, you add extra features to your generation script, further reducing the size of your various Makefile templates. You then add the ability to specify options to your script inside the template itself. Then, every small but important tweak in individual Makefiles becomes an extra configuration option that your tool can read, understand, and emit code for.

To assist with this, early on you develop a test script that takes a snapshot of all of the Makefiles in your project. Before you change the tool you take a snapshot, then you make changes, then you verify that the output (the Makefiles) is identical for all of the files. All automated of course: You have a script to snapshot, and another to check.

You then repeat until your Makefile template files are about a dozen lines long. Your script allows you to make wide changes to all of your Makefiles easily and simultaneously, and you no longer have a maintenance nightmare.

[Geti]

So with that done. I actually got to work on my game this weekend lol..

Hooray! Optimisation slog is a drag. Have you seen your software running on the real device yet? That's always a fun step for me

the stl way of doing almost anything is still pretty horrible and iterator heavy, too.

ftfy

Here is an option based on what I did when faced with something similar:

You're just solving the same problem addressed by premake et al with this though. Reinventing the wheel can be fun, but for makefile generation?..

Code:

            foreach (int i in 3.To(10))
            {
                Console.WriteLine(points[i].ToString());
            }

This is pretty much what I was expecting - it means that what Tommo posted isn't something that can be done 1:1 in C#. In his loop not only is the expression more descriptive, it gives you a "free" local reference to the object, where in yours you would have to do

Code:

object point = points[i];

to get the local, requiring another line of code and burning more precious seconds of your life
to give you a comparison with the STL way of doing it without auto or ranges:

Code:

vector<Point>::iterator end = points.begin() + 10;
for (vector<Point>::iterator it = points.begin() + 3; it != end; ++it)
{
    point& point = *it;
    //code here
}

So you can understand why he's pleased with removing most of that syntactic overhead.

edit : removed answer to 'not very smart' stuff
let's be happy instead

While I can agree with the happy sentiment, feel free to respond; this is a place for discussion and learning, not just feeling great about everything

[Garthy]

Here is an option based on what I did when faced with something similar:

You're just solving the same problem addressed by premake et al with this though. Reinventing the wheel can be fun, but for makefile generation?..

ThemsAllTook has obviously spent a bit of time in getting the Makefiles how he wants them, and is now running into maintenance problems. The solution I've offered allows him to retain that work whilst reducing the maintenance nightmare that has been arisen. It has served me well in multiple contexts, and I think it could serve him well too. You dismiss it far too quickly.

Perhaps you could instead elaborate on the benefits of premake, so that ThemsAllTook has further options. Premake could very well be the best solution to his problem.

[Geti]

Perhaps you could instead elaborate on the benefits of premake, so that ThemsAllTook has further options. Premake could very well be the best solution to his problem.

If it would help.
Premake is a build configuration system that's scripted with Lua. It allows quick, portable description of build solutions, like so: (example ripped from their site, the KAG script is a fair bit heftier, haha)

Code:

-- A solution contains projects, and defines the available configurations
solution "MyApplication"
   configurations { "Debug", "Release" }
 
   -- A project defines one build target
   project "MyApplication"
      kind "ConsoleApp"
      language "C++"
      files { "**.h", "**.cpp" }
 
      configuration "Debug"
         defines { "DEBUG" }
         flags { "Symbols" }
 
      configuration "Release"
         defines { "NDEBUG" }
         flags { "Optimize" } 

if you saved this as "example.lua" you'd then generate a makefile from it with "premake4 --file=example.lua gmake".

because it's a lua script, you can do a lot of the programmatic things you'd do in any homebrew makefile generator, just without having to do all the nasty concatenation into parsable text yourself; you just have to build the lists of files to include, defines to set and so on.

It's free, and can be found here: http://industriousone.com/premake/download

[ThemsAllTook]

Here is an option based on what I did when faced with something similar:

Write a tool (using eg. Ruby, Python, or Perl) to generate the Makefiles from a template for each file. The first pass is easy- your initial template is just the initial file, and the generator just reads the template in, line for line, and prints it out, no changes. Then, as you spot common chunks of code, you add extra features to your generation script, further reducing the size of your various Makefile templates. You then add the ability to specify options to your script inside the template itself. Then, every small but important tweak in individual Makefiles becomes an extra configuration option that your tool can read, understand, and emit code for.

To assist with this, early on you develop a test script that takes a snapshot of all of the Makefiles in your project. Before you change the tool you take a snapshot, then you make changes, then you verify that the output (the Makefiles) is identical for all of the files. All automated of course: You have a script to snapshot, and another to check.

You then repeat until your Makefile template files are about a dozen lines long. Your script allows you to make wide changes to all of your Makefiles easily and simultaneously, and you no longer have a maintenance nightmare.

Wow, why didn't I think of that? Sounds like just what I need, thanks for the suggestion!

You're just solving the same problem addressed by premake et al with this though. Reinventing the wheel can be fun, but for makefile generation?..

I suppose I should look at premake and tools like that to see if they'd fit. I have a knee-jerk reaction that makes me think they won't suit my needs since my makefiles are so meticulously crafted, but that's not a reasonable assumption to make (lol) without having looked into it.

[Garthy]

Wow, why didn't I think of that? Sounds like just what I need, thanks for the suggestion!

Not a problem, happy to help. It is a solution that works well for large, established projects, as you can make gradual changes without disrupting your existing work, and it allows you to capture your knowledge of the problem in a single place (eventually), rather than across multiple files that need to be maintained in-sync. It has saved me a lot of time over the years.

[oahda]

Time for Android development. \o/

[pxl]

Currently working on my first game in between college projects and its a real motivator.
Nice thing to bury my head in when stressed and my first games quite similar to Space Invaders but local multiplayer? I don't know, I have a playable version but one day I'll probably change a whole lot of it and then release it.

Anyway, I'm not grumpy and Game Development makes me happy, so I'll keep doing it 

[pxl]

Time for Android development. \o/

\o/  Good luck dude

[InfiniteStateMachine]

So with that done. I actually got to work on my game this weekend lol..

Hooray! Optimisation slog is a drag. Have you seen your software running on the real device yet? That's always a fun step for me

Oh yeah that's what all the optimization code has been for. It's always run fine on the simulator but the Vita itself was a little rough. I can now draw about 500-600 sprites no problem. If they are colliding it's significantly less though of course

As for the xperia phone. No way I'm buying that, hopefully it just dies soon.

[pixhead]

Dare I say it

I'm starting to like C/C++

After all the pain it put me through, I have begun to understand it's in and outs, and it's making me really appreciate the language.

[impulse9]

@pixhead

Welcome to the club.

[Evan Balster]

Code:

FreeMotion::FreeMotion(Bone *a, Bone *b) :
	Joint(a, b),
{
}
FreeMotion::~FreeMotion()
{
}

String FreeMotion::nameDOF(Uint32 i) const
{
	String s = ((i/3) ? L"Rotation " : L"Translation ");
	s.push_back(L"XYZ"[i%3]);
}

Pos FreeMotion::transform(const Bend &b) const
{
	return Pos(Point3D(b[0], b[1], b[2]), Quat(Point3D(b[3], b[4], b[5])));
}

Vel FreeMotion::dTransform(const Bend &b, Uint32 i) const
{
	return Vel(Point3D(i==0, i==1, i==2),
		Rotate(Point3D(i==3, i==4, i==5), -.5f*Point3D(b[3], b[4], b[5]));
}

Simplicity is robustness, says the engineer.
Speak little, tell much, says the artist.
They realize they are not so different.

[kamac]

Took me about 30-40 minutes, but finally got my fill tool done :3
Turns out it was only 56 lines.