As the end of the year comes closer, and we reflect on what has happened on /prog/ this last year, we have to admit that we did not accomplish very much. Perhaps in our private lives, yes, but here on /prog/ we have spent the majority of the year trolling, meta-trolling, complaining about it and going nowhere in particular. If we look at our community I'm going to say we have very little to be proud of: /prog/ kinda sucks.
I say we change all that. I say in 2012 we band together and prove that /prog/ is better than it has ever been before just by making it so. That we can come to /prog/ with an expectation of lulz and wisdom. I'm willing to make the effort, who's with me?
ITT post your new years resolutions for /prog/, I'll start:
* If I have nothing substantial to say I will sage it.
• Post programming challenges, puzzles, riddles, and discussions.
• Write some cool small programs, post them and say something interesting about how they work.
• Ignore people asking for homework help; ask and answer interesting open-ended questions. • .../prog/code golfcompetition?!
* Stop sending people back to /g/.
* Participate to /prog/ challenges.
* Make more quality posts.
Name:
Anonymous2011-12-26 6:42
Ah but something relevant now:
Is there a simple way to get textures to modify collision behavior?
I'm thinking aLa Tag: The Power of Paint and Portal 2. For me, the simplest way to think of it is as a separate texture map for the paint surface, then when an object collides with the surface the behavior changes.
Usually collision detection is done CPU side, but then we're doing "physics" with the GPU sometimes so I don't know which really covers which.
It would seem modifying geometry would be something the gpu would be relevant for, but, again, it seems most games use the GPU for effects (like normal mapping), and use low-poly and bounding boxes for CPU-based collisions detectors.
yeah, I suppose it would come down to locating the point at which the collision occurred, and then checking to see if that region of the face was affected by the special paint. I think a geometric approach for this would be easier than a texture based on, but maybe it could be done well. The geometric approach could be implemented pretty easily on the cpu side, and if GPGPU is already being used for collision detection and resolution, then it probably wouldn't be too bad to extend it to support this behavior.
* Stop sending people back to /g/.
We've chased everyone away to /g/ and /jp/ already ;_;
All there is left is the 4 of us.
May the FrozenVoid have mercy on our souls.
Name:
Anonymous2011-12-26 16:09
>>11
Geometrically, which would be more optimal, dynamically creating a polygonated surface where collisions with paint occur and putting that surface above the existing surface and assigning a bounding box collision effect (which would end up being the same as paint but probably cost alot more in memory or something), or what?
I'm trying to imagine how to do a geometric approach without creating ridiculous amounts of data or having it less complicated than simple texture pixel sampling upon collision.
yeah, which one is more optimal would probably depend on how complicated the paint patterns where. For the geometric approach, you would need to store polygons of paint on the faces of the object. If I was going to implement this, I'd probably do something like:
See if object A has collided with object B:
If so, find the point at which the collision occurred on A and B.
The point of collision is either on a vertex, the edge of a line, or in the middle of a face.
If the point of collision is on a face, then change the coordinates of the collision point to 2D with respect to the face.
See if the 2D collision point on the face is within one of the pain polygons.
If you were doing the texture based approach, then that last step would probably be a lot faster:
Round the 2D collision point on the face to pixel coordinates and see if it is on a painted pixel or not.
You'll have to store all those cells, but it'll probably be cheaper anyway, especially if you are going be painting on top of painting on top of painting. Using geometry for that would require overlaying the polygons, and you would have to merge them together if you wanted to save memory and speed. So doing the texture based approach would probably save a lot of work, go faster, and not introduce weird effects.
Name:
Anonymous2011-12-26 16:36
>>14
Alright, that's the way I was thinking of going, but I didn't really think about the sampling step. Irrlicht might be the best for me then, as even looking at the examples it provides a poly grabber, which it does not recommend to use for collision detection, but who cares what other people think.
elated, Irrlicht also has a render-to-texture feature, which could probably be simply extended for portal effects. Those are my new years resolutions, pretty much.
cool. The texture based approach could be implemented without any assistance for a graphics card if you wanted to. You would just need to store an 2D array of bits for each face, where a one indicates paint on that square, and a zero indicates no paint, although you could use larger values if wanted to introduce varying levels of thickness for the paint. It might be good to have something to fall back on in case their graphics card is ancient, but if you can get acceleration, then go for it!
oh wait, you'd probably want to render the paint as well, huh. Then yeah, I'd probably stick with textures only and stuff, and not try to rely on a separate array.
* Learn to actually program.
Might seem more personal than /prog/-related, but I've been here for years and I still can't program. It's been on my list of things for over ten years.
>>21
I have read the first chapter or two of every programming book known to man. I'm just too depressed and lethargic to bother any further.
I guess I have a motive now since my cousin's workplace needs a Python developer. Of course it's Python, but I'm not in a position to be picky.
For me, the biggest motivating factor that drives my programming is seeing what I'm able to create, and to being able to watch it run. And it doesn't stop there either, you can always take what you've built so far and use it as a set of tools to produce more and more things. It's like being an architect or a machinist, but rather than being limited by the laws of physics, you are limited by the laws of computation. But as long as you don't strive to build a skyscraper that hovers 200 feet off the ground, then you are free to build whatever you want.
>>23
I agree. I have programmed trivial things before, mostly for my own entertainment, but I think my motivation and capacity to learn died in my late teens. I guess it's more of a personal issue than an academic one since I'm a NEET and quite possibly a hikikomori. I'll ask /adv/ or somewhere later. Probably a non-4chan board.
Name:
Anonymous2011-12-26 18:50
1. To actually finish a project.
I start and make significant headway in tons of ambitious projects -- a TTS engine, a game engine, an OS kernel -- and some that are less complex but potentially more useful -- such a s a widget library for SFML that I've been working on. After a few weeks (or even days) I inevitably get bored and work on something else. As such, I still haven't finished a single non-trivial program.
2. To learn to actually design my programs. I tend to think about the problem for a bit and start writing code right away.
3. To contribute to several open source projects. I started writing a patch for the GNOME screenshot program a while ago which would put formatting in the text entry where you typed the filename (so you could put "%y-%m-%d %H:%M" and the result would be "2011-12-26 23:49") and I got bored of trying to read their code and figure out where to actually implement the feature, so I gave up and played Half-Life 2 instead.
Every month, have a competition for an implementation often a classic video game, such as Tetris. We all participate, write our own, and the winner gets nothing, but the community gets a fuckton of versions of Tetris. Who could ask for more?
>>28
What about this: every month, we have a competition for an open question, such as P vs NP. We all participate, write our own, and the winner gets nothing, but the world gets a fuckton of crackpot proofs of P =/!= NP.
Name:
Anonymous2011-12-26 19:58
What about this: every month, we have a competition for an exploratory programming in computational models of cognition. We all participate, write our own, and the winner gets nothing, but the Wikipedia gets a fuckton of Mentifex-tier total theories of AI to work with.
Name:
Anonymous2011-12-26 20:03
Every month we should post our battlestations and desktops.