Parallax
Apr 01, 2015
First of all, I know this is a little off topic, but I always want to spell "paralaxx" with two x's, not two l's. I don't know why, but I can't spell for shit, so just ignore me on all spelling related issues.
Quick post today with a short video showing parallax scrolling and actor scaling.
Parallaxing creates a nice sense of depth by just having the foreground and background layers scroll at different rates. To keep things simple, I set it up so there are two foreground and two background layers. It made the code a little easier to have a fixed number, and I don't think we'll need more.
This also shows actor scaling, which will allow Gary to create room layouts that have some depth and dimension. Actor scaling wasn't introduced in the SCUMM system until Monkey Island.
The foreground bushes are my crappy programer art.
Here is some code porn from the engine:
{
if (_images[layer]) {
_images[layer]->renderAt(GGPoint(-((_cameraPos.x-(_roomScreenSize.x/2.0f))*
_imageParallax[layer])-(_roomScreenSize.x/2.0f), 0.0f));
}
}
Simple things excite me.
- Ron
http://wiki.scummvm.org/index.php/Android/Guide
You'll need to get the data files from a copy of the game you own, but the ScummVM wiki has good guides on which files are needed and which aren't, if you're pulling them from a CD-ROM edition, for example.
BTW, isn't there a clever trick that avoids that moonwalk effect?
Maybe it's just a very minor thing but *I* find it annoying when the
foot is not fixed to the ground during walking.
Isn't there a clever way to adapt the animation frequency of the feet
with velocity of sprite movement?
I agree with you on that it looks weird but somehow I also like the effect which makes the game feel 1987-ish, I guess...
I dream of a world in which Ron Gilbert licenses his amazing engine as open source, so us underlings may have some fun following his wisdoms and pretending to make a game.
I've heard that LucasArts will be resurrected and Ron Gilbert will be the new boss and in charge of creating the first point and click-adventure game with a Star Wars-theme.
On your code.. Is a "GGPoint' a "Grumpy Gamer Point"?
I probably shouldn't be, but I'm trying to understand your code. Why is the Y position of the render always 0. Is it always 0? I guess if you don't intend to provide vertical parallax effect, if I'm understanding this correctly.
And _imageParallax[layer] looks like it would be a floating point number, taking a value of 0, for something infinitely distant - seeming not to move as the camera does (like the stars), to 1, for something immediately in front of the camera which moves at the same speed as the camera but in the opposite direction, (the foreground bushes). Or did I get that backwards.
But I have noticed that all the displayed elements in the screen have no consistent pixel sizes and raster. So you can see that the low resolution is only pretended. I hope it will get harmonised for a perfect retro-look.
But I'm also 100% sure that we're only seeing the very first attempt that assigns the character a "depth" in the room and represents this visually. I don't remember if Ron is using SDL or some other library, but I think the engine is currently just using the library's builtin sprite scaling instead of custom image scaling by Ron.
I didn't know TP was going to feature different scaling and scrolling for the characters and backgrounds/foregrounds so this is a very nice surprise =)
Will you have foreground parallax, too? I know we haven't had that until maybe Indiana Jones and the last crusade, or Monkey Island.
Here's what I mean.
( https://youtu.be/MRzspUTksDk?t=257 ) The bottleship.
Watch the video again and pay close attention.
My apologies. :)
There was some "actor scaling" in Zak McKracken albeit not within the same room
http://youtu.be/Ju5j4cobIrU?t=1492
http://blog.thimbleweedpark.com/wireframing
The SCUMM scaling might have looked like crap, but if you are working with certain resolutions constraints they should be respected, imho
I do agree that there is something "off" with the current scaling, but I want to think about it for a while. It's not a high priority right now because it's not slowing down our ability to move forward on the game. It's just a visual tweak that can happen 12 months from now. A lot of stuff is like that. You know you can solved the problem, so it just sits while you tackle more important and risky stuff.
I have thought about doing a pixel-retro™ mode that forces the pixels and truly renders everything in 320px res. If someone wanted that, they can turn it on, or maybe it's on by default and the players can turn it off. Again, not a high priority, I have more pressing things to do in the short team.
Beside the scaling thing, the position of actors, objects, parallax planes, and the cursor should IMO always fall on an integer low resolution pixel boundary, otherwise you'll get glitches that will break the "old school" illusion.
As of now, you could start rendering in a small, off screen buffer and stretch it in a nearest neighbor fashion.
Squrirrel supports integers out of box, I don't know if the / operator respects the types, though.
I did a quick search and found this site: http://filthypants.blogspot.co.at/2013/04/multipass-shaders-ntsc-motion-blur-and.html
Some of those shaders give the image a really warm, nostalgic quality. You could make such a shader optional, too.
Just a thought.
I feel like this issue is actually of some philosophical importance to the project's original promise ("It will be like opening a dusty old desk drawer and finding an undiscovered Lucasfilm graphic adventure game you’ve never played before"), which made it sound like your ambition was for the game to be more than just fashionably "retro," but to actually have its own kind of anachronistic integrity.
At least to my eye, the visual force of pixel graphics is in the fact that everything onscreen exists within a unifying grid structure. The resolution constraints of the 80s didn't just happen to inspire the "pixelly" style that people remember fondly: the constraints WERE the style. Jaggedness and boxy-ness are just superficial consequences of the larger principle that gives it aesthetic meaning and power.
When modern "retro" games have objects made of big jagged "pixels" but still render in high-resolution and do away with the grid, they reveal themselves to be, at some level, fakes, merely exercises in nostalgia. Since the visual style doesn't have any deep coordinating integrity, it's intuitively clear that the designers didn't arrive at this "pixel" concept on their own terms — they just superficially copied it from another era. As a result, the games end up feeling like second-class creations. As a player, I can't get as invested in something if it's fundamentally an imitation of another thing, instead of confidently being a thing itself. Know what I'm saying?
So, whenever you do get around to it, I urge you to consider making the true 320 resolution mandatory — not to be "pixel-retro™," but actually the opposite: to be aesthetically cohesive, here and now, rather than just dependent on fuzzy sentimental memories.
Having said that, 16:9 is great.
It's easy to get accustomed to the stretched screen, I think, because the stylized graphics never claimed to be photo-realistic anyway.
(Sorry for the double-post, but I just realized I posted in an old thread, and you may miss it.)
I just caught up with this blog and I have a question regarding the dependency charts. This may be stupid, but I'm trying to understand exactly what sort of information it is trying to convey. When a node has, say, two connections coming from above, does it mean that there are two paths to arrive at that node, or that in order to arrive at that node you must complete two other paths?
I know you've mentioned before that it's a "dependency" chart, not a "flow" chart; but I'm having a hard time making a distinction between them. Anyway, thanks for sharing your fantastic work--I look forward with enthusiasm to playing the game.
-dZ.
http://grumpygamer.com/puzzle_dependency_charts
That does help. I had read that article before, but had forgotten. I see that Mr. Gilbert points out that multiple nodes converging on a single one indicate the dependencies for the last one, so you need to "unlock door" *and* "oil hinges" in order to "open door."
Now, the part that I'm still a bit confused about is, what are the nuances to which he alludes that differentiates Dependency Charts from Flow Charts. As I work on Dependency Charts for my own game (I make 8-bit games for early 1980s consoles), they tend feel a bit "flowy".
Best regards,
-dZ.
find key -> unlock door -> open door
or
find screwdriver -> take out hinges -> open door
How is that depicted on the chart?
Thanks!
-dZ.
Hopefully you guys are good game makers.
In case you are mistaking this two year old blog post for the current state:
In the press kit you can find more current screenshots: https://thimbleweedpark.com/presskit
And here is the Steam page: http://store.steampowered.com/app/569860