We need a thread that's just a collection of all the useful algorithms posted in WAYWO.
[QUOTE=ZenX2;37451379]I added OnTick to tiles for the sole purpose of PARTY HARD
[img]http://dl.dropbox.com/u/45554193/images/PARTY%20HARD.png[/img]
It's much cooler when it's being strobarific[/QUOTE]
I'm not sure if you understand how much I appreciate this; the colossal amount of work required to get all this functionality in is too much to bear.
I'm very happy that you're filling in some details that I planned to fill in later. :)
[QUOTE=jalb;37456308]That's actually pretty clever, though I probably wouldn't treat my colors the same as vectors. It doesn't make much sense to have a dot product in your colors, for example (though you don't appear to have one, you might eventually). If it were me, I would have an entirely separate class for colors.[/QUOTE]
You'd have a separate class? Are you insane?
I mean you'd never want to use something like the dot product.
[cpp]
float3 grey(0.222, 0.707, 0.071);
float out_colour = dot(grey, in_colour);
[/cpp]
You also seem to be implying that additional methods would add overhead to the class which they don't. It would be utter insanity to create an entirely different implementation of the same thing for a colour. Vectors are not just for geometry.
[IMG]https://dl.dropbox.com/u/27714141/sfg.png[/IMG]
It's beautiful.
[cpp]#include "cilium.hpp"
#include "components/uicomponent.hpp"
namespace Cilium
{
Core::Core( sf::RenderWindow *target )
: Component("Cilium.Core"), myRenderTarget(target) { }
void Core::addedToObject()
{
myEventMsgId = getMessageRequestId("Cilium.Core.Input");
myUpdateMsgId = getMessageRequestId("Cilium.Core.Update");
myRenderMsgId = getMessageRequestId("Cilium.Core.Render");
sfg::Desktop *desktop = new sfg::Desktop();
sfg::Window::Ptr window = sfg::Window::Create();
window->SetTitle( "Hello world!" );
window->Add( sfg::Button::Create( "This is an amazing button.") );
desktop->Add(window);
addLocalComponent(new UIRootComponent(desktop));
}
int Core::run()
{
myCoreObject = myObjectManager.createObject();
myObjectManager.addComponent(myCoreObject, this);
sf::Clock deltaClock;
sf::Time dt;
myRenderTarget->resetGLStates();
while(myRenderTarget->isOpen())
{
sf::Event e;
while (myRenderTarget->pollEvent(e))
if (e.type == sf::Event::Closed)
myRenderTarget->close();
else
sendMessage(myEventMsgId, e);
sendMessage(myUpdateMsgId, dt);
myRenderTarget->clear(sf::Color(34, 34, 34));
if (sfg::SFGUI::IsAlive() == true)
sendMessage(myRenderMsgId, myRenderTarget);
myRenderTarget->display();
dt = deltaClock.restart();
}
return EXIT_SUCCESS;
}
}[/cpp]
I'm going to write the script component now (using v8), it should hook right into this framework with no problems.
[QUOTE=ECrownofFire;37459230]Is something considered threadsafe if one thread only reads from a section of memory that another thread reads and writes to? Assuming I properly lock the read-only thread out while the RW one is doing its thing.[/QUOTE]
You're looking for a rw lock I guess. Although it may be easier to just wrap a mutex around the whole thing as in certain circumstances you can into nasties like write starvation with rw locks.
Implemented Snake mini-game
[IMG]http://i.imgur.com/sXauw.gif[/IMG]
AAAAAAAAAAAAAAAAAAA BATS
[editline]30th August 2012[/editline]
may have to revise the screen shake
hi guys, sorry if this is a bit off topic but Map in a box recommended I post in this thread
[quote=Banana Lord.]is anyone interested in writing something to parse + store functions and hooks and whatnot for glua.me?
I don't have the time or patience to do it. Your contribution would be greatly appreciated by everyone, I'm sure..contact me via PM if you're interested, thanks![/quote]
sorry if this is the wrong place :(! it's been a long day
Oh hey somebody relevant did a let's play of my game
[video=youtube;FxYKu_lkY_4]http://www.youtube.com/watch?v=FxYKu_lkY_4[/video]
[QUOTE=slime73;37433259][video=youtube;PYzRuJ2RquQ]http://www.youtube.com/watch?v=PYzRuJ2RquQ[/video][/QUOTE]
Put this on Steam Greenlight.
Fixed up my weapons framework (sort of), added throwing daggers and damage indicators.
[IMG]http://i.imgur.com/kos5o.gif[/IMG]
Haha, fuck you bats!
[QUOTE=Blackwheel;37461818]Put this on Steam Greenlight.[/QUOTE]
Already planning to! :)
[QUOTE=Naelstrom;37459464]I'm not sure if you understand how much I appreciate this; the colossal amount of work required to get all this functionality in is too much to bear.
I'm very happy that you're filling in some details that I planned to fill in later. :)[/QUOTE]
Happy to help! I think this has serious fun potential, and it's great to be able to work on something in C++ with the underlying stuff already done for me :v:
[QUOTE=jalb;37456308]Also, something to be careful of with the templates: Your code isn't very portable. This line in particular:
[cpp]template<size_t length = 3, class type = float>[/cpp]
Uses default arguments for templates. This was introduced in C++11 and some modern compilers (including Visual Studio 2010's compiler) don't support this yet. Personally I say fuck the outdated compilers and keep moving ahead, but this is a heads up in case you (or anyone else) were unaware.[/QUOTE]
This statement is incorrect, default arguments for templates have been part of the standard since C++98 (and if you disagree with me, go take a look at the STL implementation used by VS20XX). What was added into C++11 are default arguments for function templates. As for why they weren't allowed is explained by Bjarne [url=http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226]here[/url]. For those too lazy to click the link:
[quote=Bjarne "Bad-Ass Mother Functor" Stroustrup;37462498]
The prohibition of default template arguments for function templates is a misbegotten remnant of the time where freestanding functions were treated as second class citizens and required all template arguments to be deduced from the function arguments rather than specified.
The restriction seriously cramps programming style by unnecessarily making freestanding functions different from member functions, thus making it harder to write STL-style code.
[/quote]
[QUOTE=Falcqn;37458952]Oh wow, that's a really cool algorithm[/QUOTE]
Meanwhile, 3D simplex noise is much faster and looks much better.
[img]http://i.imgur.com/n8Yu4.jpg[/img]
[QUOTE=Hack;37462077][video=youtube;Hqsd7giTTd4]http://www.youtube.com/watch?v=Hqsd7giTTd4&hd=1[/video]
[b]/internet[/b][/QUOTE]
I think the atmosphere of that game would be improved a lot if the ambient light levels on everything were much lower. Right now everything seems to be lit evenly from all directions, which doesn't look very realistic (or pleasing to the eye).
[video=youtube;wM3-1oAaD0s]http://www.youtube.com/watch?v=wM3-1oAaD0s&feature=youtu.be[/video]
I saw that faggot Dlaor's triangle subdivision, and I circled his square or triangle, or whatever.
[editline]29th August 2012[/editline]
I'm not sure why I made the background Pulsing Lady Pink, but I like it.
[QUOTE=qqqqqqqq;37460582]You'd have a separate class? Are you insane?
I mean you'd never want to use something like the dot product.
[cpp]
float3 grey(0.222, 0.707, 0.071);
float out_colour = dot(grey, in_colour);
[/cpp]
You also seem to be implying that additional methods would add overhead to the class which they don't. It would be utter insanity to create an entirely different implementation of the same thing for a colour. Vectors are not just for geometry.[/QUOTE]
Calm down. I never said (nor intended to imply) that methods add overhead. I also said "if it were me," implying there wasn't anything wrong with what he was doing. It's personal preference and I was just sharing mine.
Also I'm not too familiar with post processing effects so my statement of the dot product not being useful for colors may be off, but most (if not all) of that stuff happens in the shader language rather than C++.
I would just rather have color utilities in the Color class and vector utilities in the Vector class. Namespaced as well as Graphics::Color and Math::Vector.
[QUOTE=Chandler;37462498]This statement is incorrect, default arguments for templates have been part of the standard since C++98[/QUOTE]
Thanks for clarity on that. I will edit it out of my original post so it doesn't cause confusion.
[QUOTE=Banana Lord.;37460958]hi guys, sorry if this is a bit off topic but Map in a box recommended I post in this thread
sorry if this is the wrong place :(! it's been a long day[/QUOTE]
If you find no one else to do it I'll think about doing it for you.
Ontopic:
I've been working on a weather generator due to me being in Tropical Storm Isaac soon.
[img]http://puu.sh/10e7V[/img]
ALMOST
[editline]29th August 2012[/editline]
Takes a long time to generate just that. I MUST CREATE A WEATHER FAD
[editline]29th August 2012[/editline]
[t]http://puu.sh/10ekS[/t]
Pretend its a big hurricane.
[QUOTE=origamiguy;37456560]We've all done the "send HTTP GET requests to random IPs" thing.
I wrote one that sends 0xFE to random IPs on port 25565, in the hope that I might find some minecraft servers. ([URL="http://mc.kev009.com/Protocol#0xFE"]Explanation[/URL])
[IMG]http://i.imgur.com/BXxe5.png[/IMG]
I ran it overnight and woke up to 30 successful hits on the log.[/QUOTE]
Should scan the range of any successful hits (A lot of ips in the 49.212.137 range are running http servers). Doing that will result in finding a lot more. Also did you multi thread it? I would have thought you would have found a lot more for an overnight scan. Anyways would be nice to scan for general services although once you try more than a few services, scanning takes forever.
I wonder if most minecraft servers also run an http server.
[t]http://dl.dropbox.com/u/29760911/ZScreen/2012-08/zoTsk8jHxyJJF.png[/t]
[QUOTE=jalb;37463304]Calm down. I never said (nor intended to imply) that methods add overhead. I also said "if it were me," implying there wasn't anything wrong with what he was doing. It's personal preference and I was just sharing mine.
Also I'm not too familiar with post processing effects so my statement of the dot product not being useful for colors may be off, but most (if not all) of that stuff happens in the shader language rather than C++.
I would just rather have color utilities in the Color class and vector utilities in the Vector class. Namespaced as well as Graphics::Color and Math::Vector.[/QUOTE]
My mind is bogling but I'm still calm.
What you've essentially done is taken a simple concept (a vector) which has a simple representation (float[4] or your platform's SIMD intrinsic values) and made it slower (extra layer of indirection, potentially aliasing, making the structure _at least_ twice the size) and more complicated (superfluous classes with complex interactions) for absolutely no reason.
Given that a colour is represented by a vector, is it not trivial to keep your color specific functions and constants in their own namespace? float3 hsl = Colour::to_hlsl(col); float4 blululu = Colours::CornflowerBlue. You can then keep your geometry stuff in its own namespace too. Nice separation of concerns while keeping everything dead simple. That simplicity means that your compiler can do a reasonable job of optimising without even delving into SIMD intrinsics and if you do need to garner more performance it's trivial to port in support for target specific code.
This is a fantastic example of people over-using OOP for no gain whatsoever.
[QUOTE=high;37463911]Should scan the range of any successful hits (A lot of ips in the 49.212.137 range are running http servers). Doing that will result in finding a lot more. Also did you multi thread it? I would have thought you would have found a lot more for an overnight scan. Anyways would be nice to scan for general services although once you try more than a few services, scanning takes forever.
I wonder if most minecraft servers also run an http server.
[t]http://dl.dropbox.com/u/29760911/ZScreen/2012-08/zoTsk8jHxyJJF.png[/t][/QUOTE]
Some interesting points there. Scanning the range of successful hits seems like a good idea. Multithreading: yes, I had 100(!) threads running. I'm considering making it plugin-based so I can swap out different protocols/ports to scan.
[QUOTE=qqqqqqqq;37464307]This is a fantastic example of people over-using OOP for no gain whatsoever.[/QUOTE]
I'm not as interested in performance gain as I am readability. Sure "float3 hsl" may seem straightforward to you but I hate it. What does Colour::to_hlsl(col) even mean? Given a more straightforward name perhaps it wouldn't be so bad. float4 blululu = Colours::CornflowerBlue is better but still is a tiny layer of obfuscation since it can not be determined what "blululu" is by its type. One could guess blue, but not everyone has such straightforward naming conventions.
On the other hand you could define a float4 to colour.
What do you mean "making the structure at least twice the size and more complicated"? If you mean code, I do not find that a bad thing as it's easier to find everything in one spot rather than searching high and low for something trivial, which I too often find myself doing in libraries. If not, I don't understand how my approach is any worse besides increased layers of indirection (which I think can be worth the almost insignificant performance hit).
After all we're not developing top-of-the-line military simulations here. I get enough of that at work!
[QUOTE=jalb;37464721]I'm not as interested in performance gain as I am readability. Sure "float3 hsl" may seem straightforward to you but I hate it. What does Colour::to_hlsl(col) even mean? Given a more straightforward name perhaps it wouldn't be so bad. float4 blululu = Colours::CornflowerBlue is better but still is a tiny layer of obfuscation since it can not be determined what "blululu" is by its type. One could guess blue, but not everyone has such straightforward naming conventions.
On the other hand you could define a float4 to colour.
What do you mean "making the structure at least twice the size and more complicated"? If you mean code, I do not find that a bad thing as it's easier to find everything in one spot rather than searching high and low for something trivial, which I too often find myself doing in libraries. If not, I don't understand how my approach is any worse besides increased layers of indirection (which I think can be worth the almost insignificant performance hit).
After all we're not developing top-of-the-line military simulations here. I get enough of that at work![/QUOTE]
Use a typedef if you want a different name for the same thing, don't re-implement it. I meant to write Colour::rgb_to_hsl but I was thinking about hlsl so that's what we got.
The earlier implementation from that other guy put a reference (pointer) for each component into the structure. With 32 bit pointers that means you've now got a structure twice as big as it should be when holding 32 bit floats. This affects cache performance on top of the extra dereference required.
You're doing it in a way which makes no sense in terms of the machine, nor any additional sense in terms of the code. It's a blatantly horrible ingress of OOP into a simple functional domain.
This isn't about writing for supreme performance (you'd still use the same vector code but probably in SoA rather than AoS layout) it's about doing things simply and efficiently.
I'm still fighting with git, attempting to do all this pushy-pully-mergey-branchy nonsense.
What's up with things like <<<<<<< HEAD popping up in my code, it's annoying
[QUOTE=Naelstrom;37459429]Is this written in C/C++? If you're using glfw you're doing input in a bad way.
glfw has a glfwSetCharCallback() function that grabs unicode characters generated from the keyboard, allowing for modified characters (capslock, shift, alt-codes, etc). As well as supporting foreign keyboards and spaces.
Excuse me if I'm wrong, I'm assuming you're manually grabbing input from each key to generate a string; which is prone to being out of order, is very tedious to make, and is not very portable.[/QUOTE]OpenTK, and I do not believe it has any similar functions but correct me if I am wrong.
[editline]30th August 2012[/editline]
Also that guitar was remainders of when I made the server GUI screen (I took the options screen and remade it)
[QUOTE=ZenX2;37464926]I'm still fighting with git, attempting to do all this pushy-pully-mergey-branchy nonsense.
What's up with things like <<<<<<< HEAD popping up in my code, it's annoying[/QUOTE]
merge conflicts, git tells you when they happen and expects you to resolve them manually
[QUOTE=qqqqqqqq;37460582]You'd have a separate class? Are you insane?
I mean you'd never want to use something like the dot product.
float3 grey(0.222, 0.707, 0.071);float out_colour = dot(grey, in_colour);
You also seem to be implying that additional methods would add overhead to the class which they don't. It would be utter insanity to create an entirely different implementation of the same thing for a colour. Vectors are not just for geometry.[/QUOTE]
The thing you have to ask yourself when dealing with object inheritance like this is: Is every Derived a Base?
In this case, is every color a vector?
If you can truthfully say that in your project, this is always true, then by all means go ahead. If this is not the case, you've gotta get more abstract.
You could design a base class that implements the shared functionality between them, and then derive both vectors and colors from that.
Whether the methods add overhead or not is beside the point, what really matters is whether it [I]makes sense[/I]. Maintainable code always trumps efficiency.
[QUOTE=Dr Magnusson;37465310]The thing you have to ask yourself when dealing with object inheritance like this is: Is every Derived a Base?
In this case, is every color a vector?
If you can truthfully say that in your project, this is always true, then by all means go ahead. If this is not the case, you've gotta get more abstract.
You could design a base class that implements the shared functionality between them, and then derive both vectors and colors from that.
Whether the methods add overhead or not is beside the point, what really matters is whether it [I]makes sense[/I]. Maintainable code always trumps efficiency.[/QUOTE]
This idea that creating a complex inheritance tree is somehow easier to understand than a few functions that work on a plain well specified piece of data is absurd. Too much OOP kool-aid going around.
[QUOTE=qqqqqqqq;37465436]This idea that creating a complex inheritance tree is somehow easier to understand than a few functions that work on a plain well specified piece of data is absurd. Too much OOP kool-aid going around.[/QUOTE]
I am in no way advocating complex inheritance trees, but there's a reason why abstraction is neat when programming. If I want to dim a color, I wouldn't want to go through 10 vector-specific and potentially poorly named methods in order to find the one that does what I need it to do.
Colors and 4-dimensional vectors have a lot in common, like how they're added, shifted or normalized, but they also have a lot of attributes that make no sense in the other context. The thing about inheritance trees is that the ones that are well thought out aren't complex.
With your inheritance standard you still have two layers of inheritance, the vector and the color. With my suggestion you'd still only have two, but the uses and abilities of both the vector and color class would be more pronounced.
The key is to make it easy to use and hard to fuck up. If you have a color class that's derived from a vector class, does that mean that I can pass colors to functions that take a vector as one of its arguments?
Since all colors in your implementation are vectors by definition, this wouldn't be an obvious mistake to make, while it would be impossible with my implementation.
The only reason I'm taking time to write this out is that I know from experience that getting OOP right is hard as tits, and I still haven't managed it. OOP [I]is[/I] pushed like the alpha and omega of programming these days, and usually without a deeper explanation for why that is.
Sorry, you need to Log In to post a reply to this thread.
