What are you working on? V10 - Developers

Does anyone else get frustrated by by how incompatible our concept of space is to a program? To put it simply, when I run someone over in my car, the world doesn't have to check if I ran over someone two blocks away, or a guy on the other side of the planet. Even more, when I run over someone in my car, the universe hasn't just checked if I've collided with every other object in the universe. In the real world, matter, objects, people- when we are near to each other, when we collide with each other, it happens implicitly, by the laws of our universe. Sure, there's optimizations, tricks, but in the end, they're just a clever way of circumventing the fact that a simulated object is very, very alone.

[QUOTE=CarlBooth;21845703]Awesome. Can it plot the answer to life, the universe, and everything? [sp]42[/sp][/QUOTE] Yes it can: [img]http://img46.imageshack.us/img46/4036/theanswertolife.png[/img] (the label is right above the grid line, don't mistake that as being in between 40 and 42)

[QUOTE=nullsquared;21845771]Yes it can: [img_thumb]http://img46.imageshack.us/img46/4036/theanswertolife.png[/img_thumb] (the label is right above the grid line, don't mistake that as being in between 40 and 42)[/QUOTE] Zing!

[QUOTE=ryandaniels;21845727]Does anyone else get frustrated by by how incompatible our concept of space is to a program? To put it simply, when I run someone over in my car, the world doesn't have to check if I ran over someone two blocks away, or a guy on the other side of the planet. Even more, when I run over someone in my car, the universe hasn't just checked if I've collided with every other object in the universe. In the real world, matter, objects, people- when we are near to each other, when we collide with each other, it happens implicitly, by the laws of our universe. Sure, there's optimizations, tricks, but in the end, their just a clever way of circumventing the fact that a simulated object is very, very alone.[/QUOTE] That's assuming the world we live in isn't an elaborate computer program, created by a technologically advanced civilization of humans in order to simulate the world they find themselves in, such that they may uncover the solutions to their own unsolved mysteries. For all we know, it is all one giant cycle, and in hundreds of years, we will create a computer capable of simulating our own universe, hoping to observe mankind straight from its creation. These artificial humans will then one day reach a point when they too can simulate life, forming a never-ending chain of existence. It's computers all the way down. Or maybe not. Edit: After about a week of inactivity, I found time to work on my grapher again. Mainly I just reorganized a few classes and fixed a few bugs. [img]http://imgur.com/Oowcl.jpg[/img] I guess I should probably label the axis.

Polar equation? I THINK NOT! PARAMETRIC EQUATION YOU LIAR! [img]http://img708.imageshack.us/img708/926/parametric2d1.png[/img] [QUOTE=Shanethe13;21846083] After about a week of inactivity, I found time to work on my grapher again. Mainly I just reorganized a few classes and fixed a few bugs. [img]http://imgur.com/Oowcl.jpg[/img] I guess I should probably label the axis.[/QUOTE] Cool :D

I'm beginning to update my gradebook application. Going to give it a facelift basically.

[media]http://www.youtube.com/watch?v=OH4CDHtpbZg[/media] screwing around with sfml (basically I'm clicking and changing the sprite image)

Something tells me I am going to be spending a few days learning to make the GUI for my application.

[QUOTE=nullsquared;21835337]An engine? To do what? Make a goddamn game[/QUOTE] Engine: Code used to assist and/or run a game. An OBJ loader, and some render code stuck into a tiny resource manager is an engine. [editline]09:46PM[/editline] But I'm sure you'll insist we should manually load everything and handle all of the data ourselves!

[QUOTE=Jawalt;21847955] But I'm sure you'll insist we should manually load everything and handle all of the data ourselves![/QUOTE] What? Good development process: Okay, so for my game, I have these 3 .obj models that I'm going to have to render. I'm going to create a Model class that loads the models and renders them. (Later on I'll be able to reuse my Model class) Bad development process: Okay, let's make a Model class to load .obj models and render them. That way I can use it in all my future games to render all my models. (some time passes) Okay, so for my game, I have 3 .x models. Damn, now I have to rewrite all my Model code, I didn't know I'd be working with .x models.

[QUOTE=nullsquared;21848569]What? Good development process: Okay, so for my game, I have these 3 .obj models that I'm going to have to render. I'm going to create a Model class that loads the models and renders them. (Later on I'll be able to reuse my Model class) Bad development process: Okay, let's make a Model class to load .obj models and render them. That way I can use it in all my future games to render all my models. (some time passes) Okay, so for my game, I have 3 .x models. Damn, now I have to rewrite all my Model code, I didn't know I'd be working with .x models.[/QUOTE] Or: I wrote my model class specifically so it'd support as many features as possible. Skeletons, texture coords, normals, etc. Now since that's all basically structs I wrote my OBJLoader class. Now I have keep a pointer to an OBJLoader class in my Model class. I create an instance of this on init. Look what I can do now: Model->LoadOBJ("blahblah.obj") This just calls on the class to load the model. Oh shit I'm working with x now! Wait I don't have to rewrite all of those meaningless structs. I just write another loader class! Code reusability isn't bad practice. In fact some languages are built upon the idea.

[QUOTE=Jawalt;21848859] I wrote my model class specifically so it'd support as many features as possible. Skeletons, texture coords, normals, etc. [/QUOTE] That's where you fall. Prime example: look at Irrlicht and all the different formats and features that it "supports."

[QUOTE=nullsquared;21848886]That's where you fall. Prime example: look at Irrlicht and all the different formats and features that it "supports."[/QUOTE] Not really that's worked pretty good so far for me. I mean. If you make the Model class just the standard shit (vertices, and faces at first) and implement only what you need it stays clean and I can reuse the code. I do that with roundabout everything. Most model formats are really just faces, vertices, and normals anyway.

[QUOTE=Jawalt;21849014]Not really that's worked pretty good so far for me. I mean. If you make the Model class just the standard shit (vertices, and faces at first) and implement only what you need it stays clean and I can reuse the code. I do that with roundabout everything. Most model formats are really just faces, vertices, and normals anyway.[/QUOTE] Wait until you hit a bigger code-base. Then you'll look back on this discussion and agree with me. There's really nothing else I can tell you at this point in time.

[QUOTE=nullsquared;21849044]Wait until you hit a bigger code-base. Then you'll look back on this discussion and agree with me. There's really nothing else I can tell you at this point in time.[/QUOTE] I don't think so. I mean your codebase as far as model loading goes should really never get over like 400 lines or you're doing shit wrong. [editline]10:55PM[/editline] As a reference I'm looking at a OBJ loader right now and it's like 140 lines long. With a model class and an OBJ loader...

This may be a weird request but could someone write the minimum amount of code to open a simple window in windows and purposely write mistakes into it? I want to make sure I understand it by being able to fix it.

[QUOTE=Jawalt;21848859]Or: I wrote my model class specifically so it'd support as many features as possible. Skeletons, texture coords, normals, etc. [/QUOTE] And thus, you waste weeks worth of time in order to develop features that you may never have a use for. Once you get around to using them in a real-life setting, you realize that some of your implementations, while perfect on paper, are severely flawed when put to use. You then expend even more wasted effort redesigning your code to work for the task at hand, bringing the entire process full-circle.

[QUOTE=Shanethe13;21849372]And thus, you waste weeks worth of time in order to develop features that you may never have a use for. Once you get around to using them in a real-life setting, you realize that some of your implementations, while perfect on paper, are severely flawed when put to use. You then expend even more wasted effort redesigning your code to work for the task at hand, bringing the entire process full-circle.[/QUOTE] I've no idea what you guys are talking about because the entire fucking software world is built on reusable software. If you make a model class with the immediate features you will need/use or predict you will need/use you'll be fine. If you run into something you don't support you add it. You don't just bolt a kajillion things on to the model class.

[QUOTE=Jawalt;21849068]I don't think so. I mean your codebase as far as model loading goes should really never get over like 400 lines or you're doing shit wrong. [editline]10:55PM[/editline] As a reference I'm looking at a OBJ loader right now and it's like 140 lines long. With a model class and an OBJ loader...[/QUOTE] I have to agree with them. If I want to load something I won't waste time on making sure it can load every file type in existence.

[QUOTE=ryandaniels;21845727]Does anyone else get frustrated by by how incompatible our concept of space is to a program? To put it simply, when I run someone over in my car, the world doesn't have to check if I ran over someone two blocks away, or a guy on the other side of the planet. Even more, when I run over someone in my car, the universe hasn't just checked if I've collided with every other object in the universe. In the real world, matter, objects, people- when we are near to each other, when we collide with each other, it happens implicitly, by the laws of our universe. Sure, there's optimizations, tricks, but in the end, they're just a clever way of circumventing the fact that a simulated object is very, very alone.[/QUOTE] Not if you represent data volumetrically. If you use voxels then it's the complete opposite of that, actually. Using a unit of volume allows collisions to happen implicitly. They'd be on a single 3 dimensional representation of everything inside it. This doesn't work very well though, because it uses unbelievable amounts of RAM, and animations are required to lerp or something similar. Basically with a representation of something as a volume using that single representation as both the smallest piece of matter and space possible a collision is found purely when to pieces of matter overlap. And it doesn't take object versus object testing. It just takes the code to know that if two pieces exist in the same spot then do something to fix it. As a side note this is also extremely CPU intensive. So most things using voxels are limited to simplified versions like used in terrain, or the entire scene isn't rendered using them. It's basically simplified raytracing if you implement some type of tree structure. [editline]11:19PM[/editline] [QUOTE=darkrei9n;21849417]I have to agree with them. If I want to load something I won't waste time on making sure it can load every file type in existence.[/QUOTE] I don't know if you read my post at all. I suggested you create a Model class for common things existing in a model and add as needed. That's not making a model class for everything in existance.

[QUOTE=Jawalt;21849500]Not if you represent data volumetrically. If you use voxels then it's the complete opposite of that, actually. Using a unit of volume allows collisions to happen implicitly. They'd be on a single 3 dimensional representation of everything inside it. This doesn't work very well though, because it uses unbelievable amounts of RAM, and animations are required to lerp or something similar. Basically with a representation of something as a volume using that single representation as both the smallest piece of matter and space possible a collision is found purely when to pieces of matter overlap. And it doesn't take object versus object testing. It just takes the code to know that if two pieces exist in the same spot then do something to fix it. [editline]11:19PM[/editline] I don't know if you read my post at all. I suggested you create a Model class for common things existing in a model and add as needed. That's not making a model class for everything in existance.[/QUOTE] Instead of doing that, why not for example. Say we have a model in a .max, and we need it in .obj, why not open it in a third party program and save as. It would be a waste of time to add code to open a different file when you can just save it under the type you do support.

[QUOTE=darkrei9n;21849615]Instead of doing that, why not for example. Say we have a model in a .max, and we need it in .obj, why not open it in a third party program and save as. It would be a waste of time to add code to open a different file when you can just save it under the type you do support.[/QUOTE] Because different file types have different features. That's like saying to make a 2d engine and only load straight up RGB bitmaps, and save as. Let's not because there are other file formats that have more channels and more bytes per pixel than that and other features.

[QUOTE=Jawalt;21849667]Because different file types have different features. That's like saying to make a 2d engine and only load straight up RGB bitmaps, and save as. Let's not because there are other file formats that have more channels and more bytes per pixel than that and other features.[/QUOTE] Than why did you code that in the first place? Its like getting a dog that only knows how to sit, when there's a dog that is near exactly the same but it knows rollover and lie down and is potty trained.

[QUOTE=darkrei9n;21849731]Than why did you code that in the first place? Its like getting a dog that only knows how to sit, when there's a dog that is near exactly the same but it knows rollover and lie down and is potty trained.[/QUOTE]You're arguing your own point against yourself. First you say you shouldn't make one thing that tries to do everything and now you say you should? What if I don't need my dog to lie down?

On the Engine/Game debate.. Even though you shouldn't make an engine, but instead a game. I think it's a good idea to at least write something for the common features. Mostly bases I guess, Networking Basics, Window Interface, Resource Storage, Input, and File Reading. Getting it all integrated nicely makes writing specific features a lot easier. Just my 2 Cents. [editline]08:23PM[/editline] Finished Writing a File Editing Class for my project, it's really simple and easy to use. [cpp] #include "seEditor.h" int main() { se::Editor Demo( "DemoFile.txt" ); // Constructor opens file Demo.Write( "Demo Line 1\n" ); // Write adds a line to the file Demo.Save(); // Saves the contents of a file Demo.Load( "DemoFile2.txt" ); // Loads a new file, if a previous file was opened that file is automatically saved and closed. Demo.Write( "Demo Line 2\nDemo Line 3\n" ); // Write can also add multiple lines to the file printf( "Single Line: %s\n", Demo.Read( 2 ).c_str() ); // You can easily grab a line from the file, if the line doesn't exist it grabs the next highest line std::wstring WideString = Demo.ReadWide( 2 ).c_str(); // This function only exists for use in Irrlicht, because they like wchar_t*, which isn't used much by other libraries. Demo.PrintAll(); // Prints the contents of the file, line by line } [/cpp] Console Output: [code] Single Line: Demo Line 3 Demo Line 2 Demo Line 3 [/code]

[QUOTE=Jawalt;21849500]Not if you represent data volumetrically. If you use voxels then it's the complete opposite of that, actually. Using a unit of volume allows collisions to happen implicitly. They'd be on a single 3 dimensional representation of everything inside it. This doesn't work very well though, because it uses unbelievable amounts of RAM, and animations are required to lerp or something similar. Basically with a representation of something as a volume using that single representation as both the smallest piece of matter and space possible a collision is found purely when to pieces of matter overlap. And it doesn't take object versus object testing. It just takes the code to know that if two pieces exist in the same spot then do something to fix it. As a side note this is also extremely CPU intensive. So most things using voxels are limited to simplified versions like used in terrain, or the entire scene isn't rendered using them. It's basically simplified raytracing if you implement some type of tree structure. [/QUOTE] That's really cool... I was thinking something along these lines, except linearly; I was thinking how members of a list collide. But until you said this, I didn't fully realize the implications.

It's because of these arguments that WAYWO pages go by so fast We're already on page 6

[QUOTE=nullsquared;21845476]Oh did I mention it can plot a table as a set of points and also compute linear regression? [code] plot2points points linear2fit points [/code] [img]http://img23.imageshack.us/img23/669/linearregression1.png[/img][/QUOTE] Sweet. Maybe your next step could be to implement linear programming algorithms by simplex and graphing methods. :v: Or even a feature that auto-uploads the graph to the internet and returns you a link to the image?

If you chuck in stuff like finding intersect points, finding intercepts, etc. this can replace my graphics calculator :>

tbh building a real engine from scratch would be stupidly cool, it would totally be worth it even if you never built the car. If you want to write an engine, write an engine. If you want to write a game, write a game. Jesus it's not that hard.