Here’s a quick, very quick, overview of how I did that cool view in ASCIIpOrtal.
Bear with me, guys, this is still a learning experience. The frame rate is up, but so is the grainy-ness. And that explanation went by way fast, but trust me, this video was long enough as is.
Tell me what you thought of the really sped up drawing illustration with the kinda sped up voice thing. Did it work? Did it not? Did it go to fast to be any good? Leave a comment!
Hope you like the doodle, too. It was a bit like sharpie on post-it note, but if you’d like a closer look, click here.
RSS Comments.
October 15th, 2009 - 5:21 pm
The speed seemed fine to me. Watching via browser you have the luxury of as many pauses as you need, anyway.
Copying/pasting the drawing and erasing the bits off it was an excellent way to get the idea across.
October 15th, 2009 - 5:23 pm
What software did you use for the screen/voice capture?
October 15th, 2009 - 9:51 pm
I use camstudio for all my screen captures. For the voice capture and audio edit I used Audicity. For the parts when it’s my face in front of the camera I just used the capture utility that came with my camera. then I strung it all together with windows movie maker.
Total cost: for software $0.
October 16th, 2009 - 2:52 pm
I really enjoyed this video, I think you’ve inspired me to make video dev blogs, too (I made one but was kind of discouraged)
October 19th, 2009 - 4:14 pm
That’s a really good video. I’ll probably use something like that for the portal game I’m working on. Well, when I move over from Python to C.
October 22nd, 2009 - 8:05 am
Excellent video, it’s really great to see this sort of thing! I wish everyone explained the tech behind their games like this, the world would be a better place.
The only thing I don’t understand is whether you were being sarcastic or not when you claim to have invented portal rendering! AFAIK the process of recursively clipping of the view volume to the portals is the origin of the term “portal”, which is/was a popular method for rendering. Also called “beam-tracing” in the context of acoustic simulation (you might want to check out some beam-tracing papers for inspiration on possible extensions to the game concept, as they get into reflection and refraction of the “view volume”).
Also, contrary to your initial claims, you _are_ using raycasting, sort of: when you shoot rays from the player through the edges of the portals and remove the volume lying on the outside of either ray, you’re marching through a grid along a ray.. ;p
October 22nd, 2009 - 8:47 am
Hmm, well that’s interesting. My surface level research of beam-tracing doesn’t convince me that’s what I’m doing here, but it’s still interesting. It doesn’t seem to have that “cut and paste” feel of what I was doing, tho. But maybe that’s because I’m trying to see how a 3D process can be applied to a 2D plane.
At least give me credit for figuring it out in a vacuum, K?
As far as this being ray casting, I think more emphasis needs to be on your “sort of”. Very “sort of”. In face it’s loose enough that I have a hard time shoehorning what I’m doing into that definition. I’m not marching through the grid along a ray from the direction of the source. In fact I’m not really marching along the ray. I’m gonna stick by my guns here and say you haven’t got me convinced, and take your smiley at the end as sarcasm. :-P Back at you.
October 22nd, 2009 - 12:29 pm
Just to be clear, I love your game, it’s really well-done and I think the way you applied a continuous-world technique to a grid-based world is very cool.
It’s hard to believe you weren’t aware of portal-based rendering since, well.. I’ve never made a 3D game, but I’m aware of the technique because around the late 90s/early 00s everyone was writing portal-based renderers and tutorials. Every game programming site like Flipcode or Gamedev.net has at least one or two portal tutorials.
Also, the keyword is even in the title of the game! It’s sort of like if Doom was called “BSP” ;p
Anyway if you were unaware, that’s amazing because it’s quite a cognitive leap. At least, it took me a while to understand things, and that was _with_ a tutorial explaining it all! :)
Beam-tracing is just one application of portal-based “visibility”, which is how Portal works and how many 3D games work — and in fact Q3A used portals for non-physical effects (e.g mirrors, and those teleporter “portals” which acted like windows into the space you would teleport to).
For example see:
http://www.cs.virginia.edu/~luebke/publications/images/portals.plate2.gif
http://www.cs.virginia.edu/~luebke/publications/portals.html
This is why Portal is sort of a really great special thing, they didn’t *invent* anything, they just took a very old/established technique from the 90s and totally reimagined in/approached it in a fresh way — extending it to handle the hall-of-mirrors problem (when a portal can see a portal) which would break a normal portal-based renderer, and figuring out how to get physics/etc working instead of just visibility.
Anyone at any time could have done it, it was under everyone’s noses, but no one had the insight/imagination to make that leap. IMHO this is much more impressive than if it had been invented from scratch, to so thoroughly re-invent something that’s standard/taken for granted is like magic.
As for the raycasting, I suppose it depends on if you’re actually implementing your “copy+erase” method as it’s described, which I assumed was a simplified “so that it’s understandable” description; in reality I would assume you’re doing a “selective copy” rather than “full copy + selective erase”. As far as I can figure out, the boundary of the visible region through a portal on either side is exactly those cells touched by the ray from the player through one end/edge of the portal. I have no idea how you would determine this boundary *without* marching along a ray, unless you’re brute-force testing each cell in the map to see if it lies within the visible region.
Anyway, thanks again for the video.. I always want to know how everyone else’s stuff works, it’s really nice to actually be given the information rather than having to endlessly speculate!
October 22nd, 2009 - 1:01 pm
Apparently there’s no limit on the size of comments in wordpress. Heh.
Dude, just to be clear, I think you’re fantastic. Are you the guy who made N or did you just use that as your link? You like to do the tutorial’s too, and I think that’s awesome.
So maybe I should make a follow up video with some psuedo-code and examples of the math I used. I’d never heard of the portal rendering or dug much into it because I wasn’t much of a programmer when all those concepts you were talking about were big. But I am a big math guy.
I didn’t need to walk through the ray because all I needed was the area above or below the line. That’s just linear algebra. Take 2 points, call them x1,y1, x2,y2, and figure out the slope by m=(y2-y1)/(x2-x1). Then I calculated a constant which I called mxb = m * x1 + y1. Then I walked through the entire map and, here’s some psuedo code:
for all points x,y:
if (mxb > (m*x+y)) delete that point x,y from the map
else leave it alone.
when finished with all x,y points write left alone points to screen.
Or I might have had to switch the > for a < in some cases. But bascially I didn’t need to walk down the line, I needed all points above or below the line, and that’s how you do that. It’s all there in draw.cpp in the source code.
Part of how I got there was I listened to the audio commentary on the portal game and at one point they talked about how they did the portal mechanic, which IIRC was described as setting up a camera in the remote location where the other portal was and using it’s view on the wall. Now that I think about it, that’s the portal rendering you were talking about, but for me I thought “It’s all just an optical illusion, a sham. It’s a flat image that’s updated as you move to look like it’s 3D, but it’s really just a picture on the wall.” And that mentality got me thinking about how to do portals in ASCIIpOrtal.
So I guess I was in less of a vacuum than I thought, but not as informed as you thought. Heh.
October 22nd, 2009 - 1:34 pm
Yep, I’m one of the two programmers behind N; we really can’t wait to write more tutorials about the new game! We both really like learning how other people have solved problems, it’s really rewarding and interesting.
Thanks for the pseudocode, that makes sense now!
I find the “y=mx+b” form of lines very confusing; if you consider the direction of your line to be d = p2-p1 = (x2-x1,y2-y1) then you could use an equivalent vector-based test like “if(Dot(Perp(d), p-p1) < 0), p is on the left side of the line through p1,p2".
I guess it all works out the same in the end :)