Bio Force Ape was fake. Someone went and made it real.
A little off topic, but
the unreleased prototype has been foundand will probably be released for free.
Nice, thanks to TheRedEye!
Also, with FCEUX frame miss on FCEUX, Watching the numbers tally up from the intro screen is hilarious. This code must be terrible. Oh well, so cool none the less!
Finally!! I've been wanting to suplex some mutants for quite a while
I like how they actually paid more than 2k $ (moneys) for it.
Always nice to see that some unreleased games are actually enjoyable, unlike Cheetahmen 2 for example.
After the axis of the earth changed from the earthquake, I'm not surprised anymore that Bio force ape just came out. Now what will be next... Duke nukem forever, if we're lucky
Banshaku wrote:
After the axis of the earth changed from the earthquake, I'm not surprised anymore that Bio force ape just came out. Now what will be next... Duke nukem forever, if we're lucky
Wow...that is great!
Maybe we can think the opposite....maybe it won't get delayed again!
I played it some. The first fall is just a total "WTF is going on?" time, but once you hit the ground and start going, it's pretty good! Awesome.
So... this was NOT an april fool ??
No, this is the real deal. The real Seta prototype brought to you by real communism. But at this point, does ProgAce still want to finish his fan game?
Hey, this actually isn't that bad! Level design is a little lackluster, but it's actually... kinda good...
So, wait. This isn't an April fools joke? I am really confused now
qbradq wrote:
So, wait. This isn't an April fools joke? I am really confused now
No sir, no joke. I just DLed the Rom. It's the same game that I saw in the 1upvideo:
http://www.1up.com/news/game-night-bio-force-ape
tepples wrote:
No, this is the real deal. The real Seta prototype brought to you by real communism. But at this point, does ProgAce still want to finish his fan game?
It's my understanding from talking to him , that his hoax game is done. a few glitches to clean up, but really it's ready to go.
I hope he does release it so dur butter monster will live on. The real game has no butter monster
I can't seem to find the ROM download. Am I damaged?
Can someone tell me what mapper this thing uses? Any chance we'll see high-resolution PCB scans?
qbradq wrote:
I can't seem to find the ROM download. Am I damaged?
Check the very very bottom of the page I linked to.
RT-55J wrote:
qbradq wrote:
I can't seem to find the ROM download. Am I damaged?
Check the very very bottom of the page I linked to.
Yeah, I missed it (the link) the first time I went there.
So they sat on the ROM for nearly one year just because they wanted to release it on april 1st as a joke?
tokumaru wrote:
So they sat on the ROM for nearly one year just because they wanted to release it on april 1st as a joke?
Well, we've waited years and years for it, a few months more wasn't going to kill us.
Don't get me wrong, I'm not complaining about the delay. Personally, I was never very interested in this game, and after trying it out for a minute or so I came to the conclusion that it's pretty bad and I will probably never fire it up again. I just think it's a bit silly to wait this long just to make a little joke, since they were going to release it anyway.
tokumaru wrote:
I just think it's a bit silly to wait this long just to make a little joke, since they were going to release it anyway.
Those are my favorite kind of jokes.
I think it's quite normal for people acquiring rare/prototype/whatever carts to not release the dumped ROM immediately. Actually these cost money and maybe time and effort to locate the copies, so it isn't even wrong for the "collectors" to keep the games to themselves and not releasing the things. It's a good thing that this game is eventually available to the public, and I think this delay is quite understandable and releasing it on that ONE day is PERFECT time considering what has ever happened relating to it, whether the real game is crappy or not is irrelevant.
tokumaru wrote:
Don't get me wrong, I'm not complaining about the delay. Personally, I was never very interested in this game, and after trying it out for a minute or so I came to the conclusion that it's pretty bad and I will probably never fire it up again.
So did I. It's a lot of talk for a little thing if you want my opinion.
Well, if nothing else, Bio Force Ape proves that the NES is capable of BLAST PROCESSING, given how fast the screen can scroll here. When scrolling, it updates two rows/cols of tiles at a time, plus the row/col of attribute bytes. The game doesn't scroll faster than 15 pixels in any direction though.
Still though, that's fast. :T
Yeah that's fast. And nobody ever claimed that it's impossible to update two rows/columns + attributes at a time, Final Fantasy games already does this (even if they scroll slower).
Scrolling speed doesn't mean much IMO. With unrolled loops you can write a shitload of data to the PPU during VBlank, and decoding one more row/column of tiles from the level map isn't that complicated/slow either, considering that most games have a block size of 16x16 pixels, and once you reach those it doesn't make much difference whether you will read all 4 tiles or just 2.
My game can scroll pretty fast, 16 pixels per frame both vertically and horizontally if necessary (updating a total of 128 bytes + attributes). If that happens every frame though there won't be a lot of VBlank time left for other updates, so palette and pattern animations might start to lag. But I doubt my camera will move that fast diagonally for several consecutive frames.
I have to agree that not many NES games are as fast as Bio Force Ape, but I have no idea why. I really don't think the hardware imposes severe limitations on scrolling speed.
Quote:
I have to agree that not many NES games are as fast as Bio Force Ape, but I have no idea why. I really don't think the hardware imposes severe limitations on scrolling speed.
Maybe not the hardware but the collision detection algorithm you are using.
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.
Also, I don't find it "comfortable" to scroll too fast, as you can't see the level that is coming at you. No, I have never been a fan of sonic
Quote:
Also, I don't find it "comfortable" to scroll too fast, as you can't see the level that is coming at you.
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.
Quote:
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.
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.
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.
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.
Quote:
Also, I don't find it "comfortable" to scroll too fast, as you can't see the level that is coming at you.
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.
Quote:
No, I have never been a fan of sonic
Yeah I know, much like I have never been a fan of Final Fantasy
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Bregalad wrote:
Also re-used screens are REALLY noticeable to the player, unlike re-used metatiles of smaller size.
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.
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/downloads/s1-ghz-act1map.png
http://www.soniczone0.com/games/sonic1/downloads/s1-lz-act3map.png
http://www.soniczone0.com/games/soniccd/downloads/scd-mm-zone1amap.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.
tokumaru wrote:
Tiny levels annoy me.
<aol>Me too!</aol>