winjer
Gold Member
Considering how weak is the GBA and lack of dedicated hardware for 3D, it is very impressive.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
OpenLara (Tomb Raider) has been ported to Game Boy Advance
- Thread starter stranno
- Start date
Considering how weak is the GBA and lack of dedicated hardware for 3D, it is very impressive.
alabtrosMyster
Banned
It has to be a fake video playing on the screen, for 1 the resolution seems to be too high.
jimjonjimmy
Member
No it's real. I played it on my GBA through a flash cart.
Elysion
Banned
Since this is all done through software (because the GBA has no 3d hardware), I wonder if similar things could be done on other retro systems. For example, would it be possible to implement things like texture filtering and perspective correction on the PS1 through software? It would be pretty wild to have PS1 games that look like N64 games (or even early Dreamcast games), without pixelated textures and wobbly polygons.
stranno
Member
Iirc, Doom devs had to do a per-line renderer to avoid texture distortion.
lostinblue
Banned
It could be done (via software) but it would be too expensive.
A better solution would be increasing the polycount to reduce the warping, which was what most devs did.
SF Kosmo
Al Jazeera Special Reporter
The PS1 DuckStation emulator has an option to correct affine texture warping as well as the wobbly geometry you see in PS1 games. I normally prefer accurate emulation over enhancements that change the look of a game, but I have to admit these look great and don't ruin the look/feel of the games.
You can also do texture filtering and other enhancments, but the results are much more hit or miss, since it can make 2D elements look blurry and blobby. Even dialing up the resolution can show cracks and seams that you wouldn't see in the original since the actual geometry calculations aren't designed for that level of precision, though you can generally get away with dialing it up to 2x without too much trouble.
lostinblue
Banned
I have to stress that's a very modern advancement to PSone emulation. It was thought to be impossible due to do how PSone rendering and GPU works.
Coordinates were non sufficient from start to finish to pull that off and unlike Saturn and N64 it didn't use anything remotely similar to OpenGL. (this is oversimplistic to say)
Last edited:
stranno
Member
Blade Arma did all of that many years before any other emulator, in his plugin gpuBladeSoft: The enhanced geometry (so called PGXP), texture replacement (8 years before Bettle PSX), link cable, etc.
But, for some reason, nowadays it is all about the uber-annoying marketing of RetroArch.
Oh, and gpuBladeSoft still has the most amazing wireframe rendering ever seen.
Last edited:
SF Kosmo
Al Jazeera Special Reporter
Sure, but it's hard to recommend very old emulation standards now. I didn't mean to imply that DuckStation was the first to do it, but it's the best way to do it now. It also isn't exclusive to libretto/RetroArch, I use the standalone version.
I wouldn't say Saturn was any more similar to the later 3D accelerated standards than PlayStation, but it used quads instead of triangles, so you wouldn't get stuff warping along the diagonal bias. In that sense it was probably more dissimilar to the later stuff, actually. It was a limitation more than an advantage except with that one aspect
Last edited:
Skifi28
Member
They said impressive, not playable/enjoyable.
stranno
Member
It is actually very playable. I'm not sure about the N-Gage version, since EKA2L1 pushes the game to 30, but it runs on par with the Windows Mobile version back in the day.
And, according to the roadmap, there are still optimizations to do.
It is certainly much more playable than the 2013 version for iOS/Android using the touch buttons and the crappy virtual joystick (one of the worst I've ever seen on these systems). But, to be fair, both had official support for some gamepads.
Last edited:
ResurrectedContrarian
Suffers with mild autism
Awesome, I can't wait to try this on my GBA w/ flashcart. I used to love playing homebrew modified versions of Doom / Doom2 on there, this looks great.
lostinblue
Banned
I was under the impression that Saturn didn't use the same method to render 3D that Sony did, which rounded coordinates internally (so they weren't correct, and thought to be impossible to obtain "correct") and snapped them on a grid which was the same as the end resolution. so, if you ran a game at 320x240 then vertices would just "snap to point" to those theoretic pixels. Very evident when emulating in HD because despite the fact you'd be running the game at 1280x960 (so 4 times the resolution) that grid would still be enforced.
But just looked at HD Saturn and it's worse than I expected, so I have to agree.
(WM version).
SF Kosmo
Al Jazeera Special Reporter
Yeah, mostly right. The PS1 used affine texture mapping, and triangle primitives, and didn't have floating point on the CPU so it did these very coarse 3D calculations that would lead to both wobbly geometry and then textures that would sort of "fold" along the diagonal bias.
Saturn, on the other hand, didn't really have a 3D GPU, it actually did 3D using tile-based sprite hardware. Textures were all square "quads" and essentially fancy sprites that could be mapped onto 3D plane. And so because of that, it sort of side-steps the warping problem entirely. But also it does have an FPU so it can do more precise 3D calculations.
So they're both pretty alien to how things are done now, with different advantages.
01011001
Banned
it's not optimized yet. it runs original settings with original meshes and textures. all that has been optimized yet is the draw distance.
once this is actually tailored to the GBA it will run faster.
but even at ~15 fps, that is faster than many N64 games ran and barely behind some high profile games like Ocarina of Time, which ran at 20fps in NTSC regions and 17fps in PAL regions
Last edited:
nkarafo
Member
Dunno about the PS1 but the N64 was capable of far more than the 99% οf its games showed. Boss studios unlocked "more power" from the machine using microcodes while developing World Driver Championship. As a result, the game uses far more polygons than any other game on the console and possible any 5th gen console game in general.
That was very late in N64's life and only a couple of devs used similar tricks, Factor 5 being the other one with Indiana Jones.
stranno
Member
Then you have to try GBADoom, a port of PRBoom for Game Boy Advance. It's FAR better than the official games, it uses the full level layout to begin with (not the Jaguar layout), and it performs almost the same as the official games. It supports Doom 1, Doom 2, Ultimate, expansions and even Sigil.
01011001
Banned
Doom wasn't even the most impressive official release... look at what these guys did to bring Asterix & Obelix to the GBA:
the biggest issue with that engine (which was also used for the Driver 2 port afaik) is the horrendous warping at the edge of the screen... and this game runs at 20fps, but for a full 3D platformer on the GBA that is not bad imo
Last edited:
Absolutely stunning.
Well they saw V-Rally 3 and Asterix & Obelix XXL running on GBA so their astonishment must have been concrete.
01011001
Banned
while those games were impressive, this right here is on another level. this is a full and direct port of a PS1 game with almost zero cutbacks compared to the original game.
and it was made by a handful of people as a hobby! that is fucking nuts!
also this game does not have the typical extreme warping on the edge of the screen which basically every 3D GBA game had. it has slight warping but not even remotely to the degree of Asterix or Driver 2/3 and games like that
Last edited:
anthraticus
Banned
stranno
Member
Open Lara engine on the ATARI Jaguar
Atari Jaguar port could happen in the future. Lets see if XProger can learn the Jaguar stuff and overcome the poor Jaguar emulation.
That should be interesting as everything I've read about the jag implies it is really really really bad at textured polygons, would also be interesting to see how tomb raider would run if it was reported to the saturn and playstation taking advantage of everything that has been learned since it's original releaseOpen Lara engine on the ATARI Jaguar
atariage.com
Atari Jaguar port could happen in the future. Lets see if XProger can learn the Jaguar stuff and overcome the poor Jaguar emulation.
I hope 32X also.Open Lara engine on the ATARI Jaguar
Atari Jaguar port could happen in the future. Lets see if XProger can learn the Jaguar stuff and overcome the poor Jaguar emulation.
IbizaPocholo
NeoGAFs Kent Brockman
lostinblue
Banned
Nicely played. With the added benefit that if he does 32X a Saturn version exists by proxy.
I think there was a port for the Saturn at some point.
stranno
Member
An Spanish dev has made an initial port to Jaguar and it runs at 2 seconds per frame xD
It only uses the 68K, which of course is the problem, RISC processors are limited by the available cache, too much rendering code for so little memory.
So the Jaguar port could end in nothing. But let's see the XProger approach.
It only uses the 68K, which of course is the problem, RISC processors are limited by the available cache, too much rendering code for so little memory.
So the Jaguar port could end in nothing. But let's see the XProger approach.
Last edited:
SlimeGooGoo
Banned
.
Last edited:
XProger is working on the 32X port (not sure if he has continued the Jaguar port).
And /bin/cat has ported it to BREW, the Qualcomm platform (Zeebo, flip phones, etc).
There have been some improvements in the N64 port, but still a long way to see something playable.
Those are all very awesome, but man tr needs a major geometry rework to fit how the 64 does things, or custom microcode
lostinblue
Banned
Not that they have this openlara engine documented and all they just might.
Doczu
Member
This just shows that it's not easy creating a real 3D game, even by mid 90s standard. Takes a looot more work than a (shitty) 2D pixel "art" platformer or VN.
SlimeGooGoo
Banned
.
Last edited:
nkarafo
Member
Yes, by default, the N64 handles less polygons than your average PS1 game but at the same time it's more efficient because it can render flat surfaces with much less polys than the PS1 would need.
The PS1 has a strong polygon engine but it uses a lot more than needed on a flat surface to avoid the whole thing warping all over the place. The N64 could still handle just as many (or more) polygons as the PS1 but it's not as easy because it needs special microcodes for that. I don't know exactly how that works, i assume the default configuration of the N64 forces a lot of extra features to the graphics that bottlenecks geometry detail. So some studios used special code to circumvent that default configuration and free more power for higher geometry. Someone correct me if i'm wrong.
Anyway, for the N64 to be able to handle Tomb Raider (with it's excess use of polys on flat surfaces) would mean to:
A) Remove those excess polys and use more efficient level geometry that the N64 can handle thanks to it's perspective correction.
or
B) Use a microcode so the N64 can handle all those extra polygons, so you don't have to edit the levels themselves.
Or maybe neither is needed, dunno. I mean, if the GBA can handle those levels, why would the N64 need such heavy optimizations? The N64 has smoothly handled much more complex games (visually) than the OG Tomb Raider even without microcodes (just look at Shadowman).
Last edited:
SF Kosmo
Al Jazeera Special Reporter
Tomb Raider's level geometry is very clearly built around quads -- the game's Saturn origins showing -- in a way that would be hard to further simplify. But it hardly seems to be pushing the limits in that regard, I would think N64 could do it fine.
lostinblue
Banned
Less but higher quality polygons with accurate coordinates and a dedicated z-buffer yes.
All these things PSone was lacking.
Well, the microcode is available, it's just that it was deprecated and taken out of the SDK shortly after the N64 launch because results were subpar and nobody was using it.
Here is the aforementioned microcode applied to Super Mario 64.
Textures get truncated by the exact same reason they did on PSone if you didn't use a bigger polygon mesh so it's comparable to an extent to how a unoptimized direct port of Mario 64 would look on PSone.
I don't think he's hitting any polygon or any other hard limit apart from texture cache.
The issue with N64 is always down to bus bottlenecks, ram latencies and strategies to mitigate/optimize it.
GBA and 3DO renderers are very software-based, that should be offloaded to the hardware as much as possible in N64's case.
4 FPS?XProger is working on the 32X port (not sure if he has continued the Jaguar port).
Well, both the Mega Drive/Genesis and the Jaguar have a Motorola 68000 as a central processor (and the jaguar one has almost double the clock frequency) so he could be making strides on both directions there.
Looks really good.
Last edited:
nkarafo
Member
It's funny though, the textures are moving all over the place but the geometry is still stable. It doesn't jitter like on PS1.
lostinblue
Banned
Coordinates on PSone were simplified. There wasn't a depth buffer and they wanted to draw polygons fast, precise coordinates would get in the way for that so they set it like a "grid" dependant on the game resolution.
This means vertices would "snap to point" a bit like the battleship table game so it had to comply to a 320x240 grid (if that was the internal resolution for the game, which means if you were to run it at 1280x960 pixels that's a 4 times increase and thus, pixels would snap 4 pixels in any given direction). I understand emulators have been able to break away from that recently but it was deemed as impossible for ages.
N64's Turbo3D microcode doesn't go as far dropping z-buffer and proper coordinates, but removes texture correction and it's hard to tell if it can but doesn't seem to be doing affine texturing (which is what PSone did, and is basically what we called Mode 7 on the SNES) but that could be a software call that isn't being made seeing the Mario 64 code expects texture correction to be at place. Also removes some other redundancy checks increasing graphical glitches and conflicts similar to the ones normal in Saturn/Psone.
Last edited:
Esppiral
Member
The Sega Saturn version is actually a port of the Playstation version, Sega just paid a timed exclusivity that forced the game to release in an incomplete state.....
stranno
Member
The main processor of Jaguar is Tom, which is a multi-purpose processor with graphics extensions (+Blitter). It can be used as a CPU, which of course was the original idea of Atari. In the end most studios (Atari included) used the 68K just because it was the most popular assembly back then and nobody really knew RISC assembly, since it was the first RISC processor ever seen in a console. Most "16-bit games" only used the 68K, the Blitter and the Objects Processor.
If XProger can handle the memory bottleneck, I think a Jaguar port should perform even better than the 3DO port. But 3DO is a more straightforward architecture.
Btw: XProger just updated the 32X port.
Last edited:
lostinblue
Banned
I'm quite unsure of that.
It's known that it was multiplat and developed at the same time for 3 platforms, and while some early decisions seem to favour Saturn seeing how reliant it is on quads, Saturn was definitely the most different of the bunch, so definitely not the lead platform unless they were taking a reverse approach to the problem (and they weren't).
But not to say that they were porting the PSone version to Saturn as that would be overly simplistic, no. Anyway out of all of them, the Saturn version should be the one not to rush.
Yes. I'm guessing XProger's first attack angle might be running it all on the 68000. Optimizing for the 32X might be an "expect the worst but hope for the best" scenario.
That being, if cpu logic is the main bottleneck and he manages 10 fps on 32X, he might reach 20 fps on Jaguar. That bottleneck being a big "if"
Last edited:
stranno
Member
Of course he is using the RISC processors.
One guy made an initial port of OpenLara to the 68K on Jaguar, weeks ago, and it ran at about 2 seconds per frame.
Last edited: