What Are You Working On? May 2015 - Developers

Problem with that would be if objects are deleted or added, plus if there are a lot of variables for an entity there's going to be a lot of code for storing specific variables, and every type of entity needs its own implementation. I feel like you could get better results if you take a more general approach like copying entire objects to a history buffer, then replacing them with their older copies if you want to step back (plus you'd get a redo function for free by doing this). I think I'll wait a bit until I've gotten level loading/saving functionality in before trying it though.

I have absolutely no clue what I am doing here... but for some reason my attempt to make a simple rectangle turned into... well... this. [IMG]http://img.prntscr.com/img?url=http://i.imgur.com/bjCNEY2.png[/IMG] (Just screwing about with OpenTK) [B]EDIT: [/B]JAAAAAY! [IMG]http://img.prntscr.com/img?url=http://i.imgur.com/U3uXAIw.png[/IMG]

Have some respect. It's [I]Dr.[/I] McWatters.

This now works in the Haskell REPL [img]http://i.imgur.com/wKCMp6Q.png[/img] I'm incredibly happy with how well it's turning out. I didn't have to sacrifice any type safety or expressiveness so it really should feel like Windows Forms in Haskell.

[QUOTE=Handsome Matt;47696830]is that andrewmcwatters [t]http://i.imgur.com/88OkNr9.png[/t][/QUOTE] haha oh man i had to do a double take, i was like 'wait did someone shop my face onto a stock image' a++ 10/10

[QUOTE=sarge997;47695914]Along with completely redoing my project from scratch because when I first started it, I was lazy and put all my files in one folder. I also remade the long noodle rig, from 19 bones to 11 each, it's obviously not quite as flexible and floppy, but it allows for a shit-ton more noodles. [img_thumb]http://i.imgur.com/nqb5Uqp.jpg[/img_thumb] [B]Getting anywhere from 66 to 71 fps in the pic above, with about 45 noodles in the bowl.[/B][/QUOTE] You should add a "noodle wigglyness" setting. That would set the number of bones per noodle.

[QUOTE=MatheusMCardoso;47697398]You should add a "noodle wigglyness" setting. That would set the number of bones per noodle.[/QUOTE] Then you could cook the noodles by increasing the bone count from 1 upwards!

i am pleased with the amount of noodle gaming innovation going on in this thread actually inspiring

[QUOTE=Handsome Matt;47696830]is that andrewmcwatters [t]http://i.imgur.com/88OkNr9.png[/t][/QUOTE] The fucking screen. Nice touch :v:

Animation, ho! [vid]http://a.pomf.se/eqjpji.webm[/vid] Jittering is only due to my recording software, it's very smooth in realtime. [editline]10th May 2015[/editline] Also, it's only using one set of animation right now, but that's just because I haven't made the others. hehe

you should consider not being Mojang and just doing movement.y += speed instead of creating a new object(s) every frame

[QUOTE=Map in a box;47697756]you should consider not being Mojang and just doing movement.y += speed instead of creating a new object(s) every frame[/QUOTE] Map in a box, rename your username to Sniper in a box, thank you.

[QUOTE=Fourier;47697792]Map in a box, rename your username to Sniper in a box, thank you.[/QUOTE] i am a navy seal sniper with over 200 confirmed kills

[QUOTE=Map in a box;47697756]you should consider not being Mojang and just doing movement.y += speed instead of creating a new object(s) every frame[/QUOTE] I used to use my own Vector class that could do that, but converting to JSFML vectors all the time was wasteful (in the context I was using it for), but this is a good time where I can use my own! Thanks for reminding me! JSFML vectors are immutable, that's why I'm doing that.

I'm not even sure what I did... [img]http://i.imgur.com/jtptF8D.png[/img]

[QUOTE=Berkin;47698202]I'm not even sure what I did... [img]http://i.imgur.com/jtptF8D.png[/img][/QUOTE] Profanity filter? Cool.

[QUOTE=Berkin;47698202]I'm not even sure what I did... [img]http://i.imgur.com/jtptF8D.png[/img][/QUOTE] Looks like windings Counts as encryption

[QUOTE=Fourier;47696454]I guess all you have to do is make action object/interface, then inherit from it. Every action/modification then gets recorded and when you press CTRL Z it just steps back.[/QUOTE] There isn't a "catch all" for undo/redo with base class. There are generally two ways: 1) [URL="http://en.wikipedia.org/wiki/Memento_pattern"]Memento pattern[/URL]. 2) Command pattern as mentioned above. Since this is a map editor I'd probably recommend the Memento. This is because odds are you already have way to serialize your map. Every time an action is done just serialize the map state and push it onto your stack. This is easier than the command pattern where you must be careful that your undo actions put you in the same state you were in before (aka command pattern is more susceptible to programmer error). The drawback to the memento pattern is that it takes up larger amounts of memory. Hopefully your map serializations are small.

I finally got vertex manipulation working, and I can snap the points to the grid! I still got a few more things left to do; hopefully I can quickly reimplement object sizing based on this manual vertex moving approach, fix my AABB, and then implement a 2D selection box for selecting groups of points. I love it when something gets finished and a whole new range of possibilities unfold.

[QUOTE=Karmah;47698366]I love it when something gets finished and a whole new range of possibilities unfold.[/QUOTE] Upgrade complete.

[QUOTE=thrawn2787;47698285]There isn't a "catch all" for undo/redo with base class. There are generally two ways: 1) [URL="http://en.wikipedia.org/wiki/Memento_pattern"]Memento pattern[/URL]. 2) Command pattern as mentioned above. Since this is a map editor I'd probably recommend the Memento. This is because odds are you already have way to serialize your map. Every time an action is done just serialize the map state and push it onto your stack. This is easier than the command pattern where you must be careful that your undo actions put you in the same state you were in before (aka command pattern is more susceptible to programmer error). The drawback to the memento pattern is that it takes up larger amounts of memory. Hopefully your map serializations are small.[/QUOTE] Another thing you get practically for free in the functional paradigm.

[QUOTE=thrawn2787;47698285]There isn't a "catch all" for undo/redo with base class. There are generally two ways: 1) [URL="http://en.wikipedia.org/wiki/Memento_pattern"]Memento pattern[/URL]. 2) Command pattern as mentioned above. Since this is a map editor I'd probably recommend the Memento. This is because odds are you already have way to serialize your map. Every time an action is done just serialize the map state and push it onto your stack. This is easier than the command pattern where you must be careful that your undo actions put you in the same state you were in before (aka command pattern is more susceptible to programmer error). The drawback to the memento pattern is that it takes up larger amounts of memory. Hopefully your map serializations are small.[/QUOTE] This is what I'm hoping I can do. After looking into the Command pattern I find it a rather clever solution but considering for example the number of parameters on a light entity I'm not so sure I'd like to implement commands for all that. Memento seems like a more straight-forward and easier to maintain solution, downside being the memory cost of course but honestly I'm not working with that much data anyway and since I haven't implemented a way to save/load maps yet I can take this into account when doing so.

I'm so happy right now! I got a whole bunch of matrix math working right. Once finishing that vertex manipulation function, I realized that I needed to deal with an object who's model matrix may be rotated, and also from a series of different viewing angles. This meant that if an object was rotated, the screen space coordinates would no longer match the model coordinates. Additionally, I wanted all movements to snap to the [I]global map grid[/I], not an object's own internal grid, so I had to employ custom matrices, inverted matrices, and a whole lot of wizardry. This is a big deal for me because I'm absolutely shit at math, but what I just wrote works [B]exactly 100% right[/B], like not just correct because of the technicality that "a computer is never wrong", but because it is functionally right and exactly how I wanted without [I]any[/I] compromises. Today is a good day!

[QUOTE=Darwin226;47698777]Another thing you get practically for free in the functional paradigm.[/QUOTE] How so?

[QUOTE=thrawn2787;47698958]How so?[/QUOTE] Well, he is not wrong, but he is being a little awkward about it, I assume he means in a purely functional context where you might treat the entire world state as an immutable structure, and every update returns a new version of the world. So for the memento pattern in that case, all you'd do is keep around a few of these immutable structures from the past instead of discarding references to them on update. You'd have something like: [code] new_state = do_update(current_state) #everything in current_state is unaffected by the update, new_state is produced with all the modifications applied ... [/code] Which is an oversimplification, but that's the gist of it :v: Though just making games in this manner is a rather monumentous task, theres quite a few people trying to, but much more than small platformers and pacman-clones have yet to emerge. So claiming it's "practically for free" is a bit generous when it comes to game development :v:

[QUOTE=Profanwolf;47699050]Well, he is not wrong, but he is being a little awkward about it, I assume he means in a purely functional context where you might treat the entire world state as an immutable structure, and every update returns a new version of the world. So for the memento pattern in that case, all you'd do is keep around a few of these immutable structures from the past instead of discarding references to them on update. You'd have something like: [code] new_state = do_update(current_state) ... [/code] Which is an oversimplification, but that's the gist of it :v: Though just making games in this manner is a rather monumentous task, theres quite a few people trying to, but much more than small platformers and pacman-clones have yet to emerge.[/QUOTE] If you look at the volume of people making games in imperative languages compared to the number of them that aren't small platformers and pacman-clones, it's not really surprising that the functional programming community, which is orders of magnitude smaller, doesn't produce those. It's a bit tiring seeing people portray functional programming as "that thing everyone is still trying to figure out". No. What I said is true. You do get that for free. The vast majority of your game state is shared between frames and the natural definitions of immutable types let you exploit that sharing. There is very little, to none copying involved. The `newState = step currentState` you wrote is exactly how it can be done. Not a oversimplification. It seems overly simplistic from an OOP standpoint because you don't get to have a tangible "state" object when your state is scattered across many different classes.

[QUOTE=Darwin226;47699146]If you look at the volume of people making games in imperative languages compared to the number of them that aren't small platformers and pacman-clones, it's not really surprising that the functional programming community, which is orders of magnitude smaller, doesn't produce those. It's a bit tiring seeing people portray functional programming as "that thing everyone is still trying to figure out". No. What I said is true. You do get that for free. The vast majority of your game state is shared between frames and the natural definitions of immutable types let you exploit that sharing. There is very little, to none copying involved. The `newState = step currentState` you wrote is exactly how it can be done. Not a oversimplification. It seems overly simplistic from an OOP standpoint because you don't get to have a tangible "state" object when your state is scattered across many different classes.[/QUOTE] Well yes, it looks simplistic from the outside, the actual complexity is on the inside, that's what I'm referring to, it would be naive to claim there's no problems with making games in a purely functional manner, not that the imperative way is perfect either, but it's not a panacea. The biggest communication problems between the communities seems to be that either side thinks their way is the "One True Way" and none of them can discuss the pros and cons of approaching it in either way. I mean, surely we can be more productive than going in where a bunch of supporters of an opposing view are and saying "You're doing it wrong, do it like I am instead.". I'd love to see any examples of released games which have been made in a purely functional language! :v: Or your own personal projects which are underway for that matter. Admittedly, the purely functional approach even if applied in languages which are not primarily functional languages can be quite beneficial, for example the imperative D language lets you tag functions as "pure" and then not allow them to have any side effects. Which could help for example in cases where you want to parallelize a certain operation, where if you know the function(transitively) doesn't have any side effects, it may be run in parallel at any scale you wish. :v: Pageking, have a picture of an old LÖVE2D project to do isometric worlds :v: [img]http://i.imgur.com/yDOUUVn.png[/img]

[QUOTE=Profanwolf;47699189]Well yes, it looks simplistic from the outside, the actual complexity is on the inside, that's what I'm referring to, it would be naive to claim there's no problems with making games in a purely functional manner, not that the imperative way is perfect either, but it's not a panacea. The biggest communication problems between the communities seems to be that either side thinks their way is the "One True Way" and none of them can discuss the pros and cons of approaching it in either way. I mean, surely we can be more productive than going in where a bunch of supporters of an opposing view are and saying "You're doing it wrong, do it like I am instead.". I'd love to see any examples of released games which have been made in a purely functional language! :v: Or your own personal projects which are underway for that matter.[/QUOTE] It's a kind of a prisoners dilemma really. Sure, it would be more productive if both sides talked about their pros and cons, but every sides optimal strategy is to only talk about the pros because if you don't, and the other side does, then you lose. I agree it's really stupid and I do try to stop myself when I see I'm doing it. In any case, I'd also love to see those examples, but again, there's that volume issue. The people that are crazy enough to stick through and learn Haskell (for example) usually get interested in the theory behind it and lose interest in making games (or practical programs, really). It sucks, but it's how it is. When enough infrastructure gets built that you can start making games without having to know what a coendofunctor is, then we might get to see examples. The reason I say thing like "you get that for free in functional programming" is because I'm hoping that someone will read that and thing "interesting, I should look into that" and maybe one day make a Haskell version on Unity. As it turns out, it just attracts dumb ratings so I'll stop doing that.

[QUOTE=Darwin226;47699297] The reason I say thing like "you get that for free in functional programming" is because I'm hoping that someone will read that and thing "interesting, I should look into that" and maybe one day make a Haskell version on Unity. As it turns out, it just attracts dumb ratings so I'll stop doing that.[/QUOTE] You can always phrase it differently, I think the only reason you get dumbs is because people are usually looking for practical help in their specific problem like with that comment, so suggesting for them to switch paradigm is a bit extreme :v: There's always other ways to showcase the usefulness, so I wouldn't give up or anything!

I got sick of always having to consult MSDN whenever I needed to find a window message code and write a constant for it, so I'm writing a library that contains all the constants in one place, with the summaries for each one. [img]http://i.imgur.com/qMQwRaJ.png[/img] I'll also be writing utility methods for retrieving the name of a message from its code, and vice versa.