|
brian posted:
Is it wrong that I feel like a proud parent?
|
# ? Feb 3, 2012 03:12 |
|
|
# ? May 9, 2024 12:26 |
|
cuatro posted:That looks awesome. Are you planning on releasing the source any time? I'd love to see how you've handled pathfinding.
|
# ? Feb 3, 2012 04:33 |
|
monsterland fucked around with this message at 00:25 on Feb 4, 2012 |
# ? Feb 3, 2012 09:19 |
|
Ephphatha posted:That looks awesome. Are you planning on releasing the source any time? I'd love to see how you've handled pathfinding. thanks! not sure about releasing the source yet. i will probably decide one way or the other once i finish the crafting and combat systems. the pathfinding is just A* with a couple of modifications. big one is probably before starting the A* i do a flood fill of the target area to make sure the target is not completely walled off, if it gets to a certain size i am assuming there is a path to the target (this i still need to work on because its not a good solution). if i dont do some sort of check like this since the world is infinite the A* will never run out of open spaces to check so it will start to suck up the memory since it never completes unless it gets cancelled. while pathfinding is going on the object will move 1 square at a time towards the target to give the illusion of being responsive then when the path is complete it signals the object and it figures out the best path from where it currently is to the closest position on the path returned by the pathfinder. usually its only 1 block or less away so when i was testing i would delay the pathfinding by 20 seconds to make sure it could find the path to the completed path properly.
|
# ? Feb 3, 2012 15:48 |
|
cuatro posted:the pathfinding is just A* with a couple of modifications. big one is probably before starting the A* i do a flood fill of the target area to make sure the target is not completely walled off, if it gets to a certain size i am assuming there is a path to the target (this i still need to work on because its not a good solution). if i dont do some sort of check like this since the world is infinite the A* will never run out of open spaces to check so it will start to suck up the memory since it never completes unless it gets cancelled. Is it even worth doing the walled-off check before running pathfinding? Your pathfinding algorithm itself should determine if it can't reach the destination, and it's possible for the destination to be unreachable even if the character isn't walled-off. I would also think that it would be uncommon for a character to be totally walled-off, so in most cases it seems like it would be a waste.
|
# ? Feb 3, 2012 19:46 |
|
It's a good idea to put some sort of limit on the A* saying that if you pass some certain threshold as far as distance traveled so far, just toss it off the stack as a not optimal solution. This will help you in roguelikes especially since you don't want to shut a door and have a mob travel 98% of the map just to get to you.
|
# ? Feb 3, 2012 20:05 |
|
In similar infinite-world games I've written, I'll keep the world stored as a grid of connected boards, and any pathfinding searches will be limited to only the actor's current board as well as adjacent boards. For dumber AI's (zombies, animals, etc.), you can actually just run a quick raytrace out to their visible range, and only run your pathfinding search within those cells.
|
# ? Feb 3, 2012 20:39 |
|
SlightlyMadman posted:For dumber AI's (zombies, animals, etc.), you can actually just run a quick raytrace out to their visible range, and only run your pathfinding search within those cells. Oh man, that's really clever.
|
# ? Feb 3, 2012 20:45 |
|
Gordon Cole posted:Is it even worth doing the walled-off check before running pathfinding? Your pathfinding algorithm itself should determine if it can't reach the destination, and it's possible for the destination to be unreachable even if the character isn't walled-off. I would also think that it would be uncommon for a character to be totally walled-off, so in most cases it seems like it would be a waste. SlightlyMadman posted:In similar infinite-world games I've written, I'll keep the world stored as a grid of connected boards, and any pathfinding searches will be limited to only the actor's current board as well as adjacent boards. yea i still have some more plans for my pathfinding, but that will come after i get all the building systems in place. right now i added the walled off check because its possible to build a box with walls and nothing can enter or exit it which can be a problem because in the demo the objects are just picking a random location to try to move to when set to wander (this wont be as much of an issue when the objects actually have a purpose to go somewhere). but what happens is the a* search will continue expanding outwards from the target area because it doesn't have a bounded set of open cells to look at. if terrain doesn't exist it will generate it and those cells will be added to the open list and so on. i have messed around with making the bounding box current section + adjacent sections and that works well unless you get into a situation where someone wants to make a great wall of china spanning multiple sections which is technically possible, so its more of just a simple check to make sure pathing doesn't get out of control. i will revisit when i have the building stuff fully figured out. cuatro fucked around with this message at 00:24 on Feb 4, 2012 |
# ? Feb 4, 2012 00:20 |
|
poemdexter posted:Oh man, that's really clever. It also has the nice side effect that it makes stealth/cover gameplay work. I suspect the better gaming AI systems actually do something like that, with occasional hilarious side effects like the fact that you can make NPCs oblivious to various things in skyrim by putting a bucket on their head, which I'm fairly certain was not on purpose (since the correct behavior would be to complain or become agro, and remove the bucket, or at least run around hilariously banging into walls for comedy relief)
|
# ? Feb 4, 2012 13:42 |
|
This new article on AI GameDev contains some interesting ideas on optimizing A* for grid-based systems: http://aigamedev.com/open/tutorial/symmetry-in-pathfinding/ Not sure how immediately applicable they are to your lazily-generated terrain system, cuatro, but they could spark some good hybrid solutions.
|
# ? Feb 5, 2012 18:10 |
|
ynohtna posted:This new article on AI GameDev contains some interesting ideas on optimizing A* for grid-based systems: Thats a very elegant solution actually. Would love to see some source code. I wonder if anyones done a python implementation e: My flatmate (the mathematician) got really excited when I asked him what he knew about "symetry" and then he looked at it and went. "Oh that sort of symetry. boring". I have no idea what he means by it. He's a "group theory" dude.
|
# ? Feb 6, 2012 09:48 |
|
ynohtna posted:This new article on AI GameDev contains some interesting ideas on optimizing A* for grid-based systems: thats a great article. ive read about JPS before, the problem with it or RSR to my game is it requires a uniform cost grid. in my game since the terrain can slow you down (walking through trees is slower than walking through grass, walking through shallow water is slower than grass), these optimizations wouldn't work because you could skip over the cost changes which could then produce a non optimal path to the goal.
|
# ? Feb 6, 2012 15:37 |
|
cuatro posted:thats a great article. ive read about JPS before, the problem with it or RSR to my game is it requires a uniform cost grid. in my game since the terrain can slow you down (walking through trees is slower than walking through grass, walking through shallow water is slower than grass), these optimizations wouldn't work because you could skip over the cost changes which could then produce a non optimal path to the goal. The author uses uniform cost grids for simplicity in the article, but is that really a requirement for this algorithm? The core gimmick involves quickly eliminating neighbors that could be reached quicker from the parent node and it should be possible to make that determination even in the case of a graph with variable edge weights.
|
# ? Feb 6, 2012 17:22 |
|
PDP-1 posted:The author uses uniform cost grids for simplicity in the article, but is that really a requirement for this algorithm? The core gimmick involves quickly eliminating neighbors that could be reached quicker from the parent node and it should be possible to make that determination even in the case of a graph with variable edge weights. true. im going to whip something real quick to see if i can get this working properly.
|
# ? Feb 6, 2012 18:08 |
|
duck monster posted:e: My flatmate (the mathematician) got really excited when I asked him what he knew about "symetry" and then he looked at it and went. "Oh that sort of symetry. boring". I have no idea what he means by it. He's a "group theory" dude. Symmetry groups!
|
# ? Feb 6, 2012 19:01 |
|
Over the weekend, I wrote a bookmarklet that allows you to quickly change the dimensions of a webpage to test responsive design. See more / install here http://codebomber.com/jquery/resizer/ Source here: https://github.com/egdelwonk/resizer
|
# ? Feb 6, 2012 23:49 |
|
wil posted:
Hey this is cool and a lot easier/faster than using other plugins. Nice
|
# ? Feb 7, 2012 18:11 |
|
That's pretty neat, but may I suggest adding a "X" button to make it go away when you are done?
|
# ? Feb 7, 2012 21:48 |
|
peepsalot posted:That's pretty neat, but may I suggest adding a "X" button to make it go away when you are done? Fork it, bro
|
# ? Feb 7, 2012 22:05 |
|
peepsalot posted:That's pretty neat, but may I suggest adding a "X" button to make it go away when you are done? Sure! I'll add that in tonight.
|
# ? Feb 7, 2012 22:08 |
|
cuatro posted:true. im going to whip something real quick to see if i can get this working properly. got a basic A* + JPS working. I need to change it slightly to look for jump points when there is a change in terrain cost, but that should be pretty easy. to see the difference in the # of nodes being put on the open list is pretty crazy. The Blue is the completed path and the orange/red are the Nodes that were put on the open list. Technically sometimes there are more nodes looked at using JPS since it recursively moves through them looking for a jump point, but less work is done overall since the open list stays much smaller. still got some bugs to fix, but overall it seems to be working out pretty good. Basic A* A* + JPS cuatro fucked around with this message at 21:51 on Feb 8, 2012 |
# ? Feb 8, 2012 15:24 |
|
wil posted:
I am going to start using this at least once a day. Thank you!
|
# ? Feb 8, 2012 16:24 |
|
I added a refraction stack and precedence system to my ray tracer. It implements a subset of constructive solid geometry to figure out the interfaces between refractive volumes at run time, rather than needing to tediously model them. This allows for things like glasses filled with liquid to be rendered correctly. The scene is also my first stab at 3d modelling.
|
# ? Feb 9, 2012 21:35 |
|
Holy poo poo, people have said this with other renders but this is the first one that's actually had me wonder if I accidentally clicked on some sort of Watch & Weight "Post pictures of your favorite glassware" thread.
|
# ? Feb 9, 2012 22:05 |
|
SlightlyMadman posted:Holy poo poo, people have said this with other renders but this is the first one that's actually had me wonder if I accidentally clicked on some sort of Watch & Weight "Post pictures of your favorite glassware" thread. The light in the shadow of the glass on the right is particularly good.
|
# ? Feb 10, 2012 00:47 |
|
steckles posted:
Goddamn that's nice looking. If you start selling a Blender version of this, I'd be interested, dependent on price/features/usability. I've been looking for a really nice Blender renderer, but in general they don't use the built-in materials very well, so you're stuck with that renderer forever once you've built a big scene with it. Something that only required its own material properties when there wasn't an already-existing property that covered the setting, such as base color (without making a branch of the existing Blender material) would be incredible.
|
# ? Feb 10, 2012 01:38 |
|
steckles posted:
Amazing, just as the previous images you posted from your raytracer. Do you happen to have a blog where you write about all these raytracing madness?
|
# ? Feb 10, 2012 02:56 |
|
thepedestrian posted:I am going to start using this at least once a day. Thank you! By request from a few other people, I've packed it up as a chrome extension. Checkout the original link to download
|
# ? Feb 10, 2012 03:28 |
|
wil posted:
This is really cool. Going to get your Chrome extension tonight.
|
# ? Feb 10, 2012 03:43 |
|
I posted a week or two ago about my c64 sprite editor. I've been doing some more c64 development in the evening, and look at this: It's a 20x12 map (surrounded by debug information) showing an implementation of the A* algorithm. It's not particularly speedy, taking about 1 second to calculate the path, but since it is iterative I can probably get away with using it in a game if I amortize the cost over a whole bunch of frames. Whee!
|
# ? Feb 10, 2012 14:37 |
|
Sagacity: That's pretty rad. In that kind of situation I'd be tempted to go with a simple flood-fill algorithm over A* because A* normally involves maintaining more complex data structures. Care to go into some detail about your implementation?
|
# ? Feb 10, 2012 15:53 |
|
Internet Janitor posted:Sagacity: That's pretty rad. In that kind of situation I'd be tempted to go with a simple flood-fill algorithm over A* because A* normally involves maintaining more complex data structures. Care to go into some detail about your implementation? But flood-fill would probably take even more time. The implementation is fairly straightforward, I basically implemented the "Summary of the A* Method" from here. I have 5 things that I need to store per tile: G (the number of steps from the start), cost (G + H), the open list, the closed list and the tile's parent. Because my map is 20 * 12 this takes 240 bytes per list, so it's 1200 bytes in total, which is okay. Most of the time goes into adding and removing things from the open list. Removing a tile means shifting all subsequent tiles back, which takes a bit of time. So instead of adding tiles to the list, I'm thinking about doing something like openList[tileOffset] = true; That would mean it would take longer to find the lowest cost 'open list' tile though, because traversing would increase in complexity. Oh well. Edit: Yep, the "openList[tileOffset] = true" approach works quite well. It allows me to combine open and closed lists by just saying that "list[offset] = 1" means it's on the open list, and "2" means it's on the closed list. So it saves me 240 bytes as well. Now if only I could avoid the expensive step of finding the lowest cost somehow... Grab the demo here: http://dl.dropbox.com/u/512956/astar.prg Press firebutton in joystick in port 2 to advance through a few routes. Sagacity fucked around with this message at 19:03 on Feb 10, 2012 |
# ? Feb 10, 2012 17:23 |
|
Sagacity posted:Now if only I could avoid the expensive step of finding the lowest cost somehow... if your using C++ use a heap. thats what I am using in my A* implementation posted earlier. http://www.cplusplus.com/reference/algorithm/make_heap/ basically when you add something to the open list you call push_heap and to remove the lowest cost call pop_heap. keeps that operation nice and quick when getting the next node to expand.
|
# ? Feb 10, 2012 19:00 |
|
cuatro posted:if your using C++ use a heap
|
# ? Feb 10, 2012 19:04 |
|
wil posted:By request from a few other people, I've packed it up as a chrome extension. Checkout the original link to download This is really, really minor but if you use this on a site with SSL it makes Chrome very angry.
|
# ? Feb 11, 2012 03:24 |
|
A screenshot utility I wrote quite awhile ago that I'm in the midst of cleaning up and productizing. (Screenshot of the application... taken with the application... Inception joke, anyone?) Placement on the desktop for some reference: The goal is a simple, compact interface that creates documentation quality screenshots that look like this: ...instead of this (which is all too typical on blogs and forums these days): I've got quite a few features already written, mostly what's left is polish and to move some hardcoded things into the Options window. Here's a video of me demonstrating how you'd use the 1-click upload feature: https://www.youtube.com/watch?v=FA6JNs5f9Iw
|
# ? Feb 11, 2012 05:03 |
|
I have been playing with processing quite a bit of late and have to say I am really enjoying it https://vimeo.com/36548291
|
# ? Feb 11, 2012 09:03 |
|
Since I already done a NES emulator for a coding contest (the emulator is less than 64kb), figured I move onto GB/GBC, and eventually GBA. So I started coding this. This is written according to a completely different methodology, so C++ is heavily used, as well as modern APIs like WTL for the GUI, Direct2D for video, Xaudio2 for sound and Xinput for input support. The renderer also supports D3D8, as well as Direct3D9. Support for GDI, DirectDraw and OpenGL is also planned, for completeness. Emulation wise, there is a few CPU core issues to fix, like proper instruction behaviour and core timing. Bandlimited audio synthesis for sound emulation also would be nice. I am focusing it for gamers, so things like disassemblers, and tile viewers are omitted. However things like GPU based graphics filters are planned, and I am considering audio DSP effects like reverb, and echo too. I have been working on some other things, like a PE32/possibly x64 executable file packer (think UPX with plugins/DRM), as well as working with kode54 on replacement MIDI synthesis drivers for Windows 7 and Vista (x64 included.) mudlord fucked around with this message at 13:59 on Feb 11, 2012 |
# ? Feb 11, 2012 13:52 |
|
|
# ? May 9, 2024 12:26 |
|
Factor Mystic posted:screenshots Doesn't ctrl alt print screen do the same thing? Oh the screenshot to imgur thing is amazing.
|
# ? Feb 11, 2012 17:10 |