Stargate (SNES) does that but it ends up being even worse as the camera oscillate a lot during gameplay and you'll end up with an headache.Hey, can anybody think of an example of a game that adjusts the screen so that you can see farther ahead when scrolling? I know that there are some out there, but I can't think of what they are at the moment.
Bio Force Ape found
Moderator: Moderators
Useless, lumbering half-wits don't scare us.
How many games do you know that have walls thinner than 16 pixels? Except for a few first-generation NES games I can't think of any. As a general rule, the maximum displacement for characters should be the size of your smallest collision entity (blocks, metatiles, whatever), so that you don't miss any.Bregalad wrote:For example if you are running very fast in front of a very thin wall, chances are that the game could allow you to just go through it if you are scrolling too fast.
I think games can have speed sections (not whole levels) if the levels are well designed and don't have you run into hazards you can't see. Sonic games rarely punish you for going fast... levels don't have walls of spikes or bottomless pits after speed sections. The good thing about Sonic (the old games, I mean) is that you don't have to go fast, you can move pretty slowly if you want to, just accelerating to go through occasional loops and things like that.Also, I don't find it "comfortable" to scroll too fast, as you can't see the level that is coming at you.
Yeah I know, much like I have never been a fan of Final FantasyNo, I have never been a fan of sonic
On the NES? I can't name any right now, but I'm sure there are some. On the Master System, Daffy Duck in Hollywood comes to mind. That game has extremely smooth scrolling, and it adjusts the camera to display more of what's in front of you.RLError wrote:Hey, can anybody think of an example of a game that adjusts the screen so that you can see farther ahead when scrolling?
Yoshi's Island for Super NES will scroll the screen depending on which way Yoshi is facing such that more of the screen is in front of Yoshi than behind.
But fast scrolling for a long period of time needs a large level, and a large level needs lots of ROM and lots of time to create, unless it's made of simple repeated building blocks like level 3 of Battletoads.
But fast scrolling for a long period of time needs a large level, and a large level needs lots of ROM and lots of time to create, unless it's made of simple repeated building blocks like level 3 of Battletoads.
I noticed that the only time the game scrolls super fast is when you're on a lift. I guess the lifts are planned out such that they can't collide with anything, they just have a start point and zoom as fast as possible to the end point.
Otherwise, your falling is limited to something like 7 pixels per frame, and your running is even slower than that.
Otherwise, your falling is limited to something like 7 pixels per frame, and your running is even slower than that.
Some games use map compresion schemes where each block is 256x256 pixels large (Sonic 1 and Mega Man X are examples of this), which means that levels can be pretty large without requiring much ROM, specially if the individual blocks are compressed further. A level that's 128 screens wide (you'd need about 34 seconds to go through all of it at 16 pixels per frame, that's fucking huge) could be defined in only 128 bytes, at the price of having a number of repeated screens (not uncommon in platformers). Of course I'm not considering the space taken by the blocks themselves, but like I said, they can be compressed too.tepples wrote:a large level needs lots of ROM and lots of time to create, unless it's made of simple repeated building blocks like level 3 of Battletoads.
If the blocks are 256x256 pixels then I guess you should call them "screens".
And then I sure hope the individual screens are further compressed otherwise they're going to take a damn lot of space.
If your level is basically :
Level:
.db 1, 2, 3, 4, 5, 6, 7, 8
.db 9, 10, 1, 11, 12, 4, 13, 14
And that each screen is uncompressed, you'd almost say the level is uncompressed.
Also re-used screens are REALLY noticeable to the player, unlike re-used metatiles of smaller size.
Personally I really do NOT like games which re-use screens for another purpose than a labyrinth. It looks cheap-ass as hell.
And then I sure hope the individual screens are further compressed otherwise they're going to take a damn lot of space.
If your level is basically :
Level:
.db 1, 2, 3, 4, 5, 6, 7, 8
.db 9, 10, 1, 11, 12, 4, 13, 14
And that each screen is uncompressed, you'd almost say the level is uncompressed.
Also re-used screens are REALLY noticeable to the player, unlike re-used metatiles of smaller size.
Personally I really do NOT like games which re-use screens for another purpose than a labyrinth. It looks cheap-ass as hell.
Useless, lumbering half-wits don't scare us.
Crystalis (MMC3, 256K prog / 128K char) stores "screens" as uncompressed sets of 16x15 meta-tiles (256x240 pixels). These screens are located at the very beginning of the ROM. Actual "areas" that the hero can walk around on without loading a new area are generally 8x8 screens or smaller (largest is the Cordel Plain, the area outside of Brynmaer and also the save in the desert with the power ring). The cart dedicates 64K to storing these "screens", or 1/4 of the prog-rom space, and probably another 32K or so to store the meta-screen ("area") tables and metatile -> tile tables.Bregalad wrote:If the blocks are 256x256 pixels then I guess you should call them "screens".
And then I sure hope the individual screens are further compressed otherwise they're going to take a damn lot of space.
Having the data uncompressed makes it easier for the game engine to quickly do terrain navigability tests for each actor. The game play is very smooth. CPU time is not wasted doing lots of decompression. The trade-off is ROM space used and the repetitive nature of the maps (ie, NE corner of every valley looks the same).
I would further guess (since I did disassemble the game back in 2000 ~ 2001), that the game uses around 128K to store the maps, their meta info, palettes, rendering code and navigation code. That's about 50% of the prog-rom space. For a game that is about exploration and supposedly taking place in Europe and North Africa (hint: flip the world map upside down and compare with the Earth), this seems reasonable to me.
That really depends on the kind of game and the kind of graphics. For a linear game that's only 1 screen tall this doesn't make much sense, but in maps that are several screens tall the amount of data saved when compressing the sky is huge. A screen with just blue sky and clouds can be repeated forever without drawing much attention. The same goes for dirt/rocks/etc that usually exist below the floor.Bregalad wrote:Also re-used screens are REALLY noticeable to the player, unlike re-used metatiles of smaller size.
The trick is to reuse the more generic pieces a lot, but reserve the more characteristic ones for special places. You can also "decorate" the screens with objects to make them slightly different.
Looking at the maps in Sonic 1 and Sonic CD (the 2 games that use 256x256 blocks, the others use 128x128) I really don't see that much repetition:
http://www.soniczone0.com/games/sonic1/ ... ct1map.png
http://www.soniczone0.com/games/sonic1/ ... ct3map.png
http://www.soniczone0.com/games/soniccd ... e1amap.png
Of course that when zoomed out like this the parts that are just solid ground stand out a lot, but the areas that you actually see during gameplay don't feel repetitive at all IMO. I think that the huge levels are worth it. Tiny levels annoy me.
