Yeti3D Pro [N64]

[ChillyWilly]

Nickname: Chilly Willy
Project Name: Yeti3D Pro
From: USA
Division: GAME
Platform: N64
Original Entry: NO (PORT)
In last NEO Compo this project have won in the top 10: NO



Here's my entry for this year's compo. You might think you have seen this before - back when I first started on N64 homebrew, I made a quick port of Yeti3D GPL - the old, limited version. This is Yeti3D Pro, a far more complete version of Yeti3D.

You can find the original release of Yeti3D Pro on SourceForge here:
Yeti3D Pro: http://sourceforge.net/projects/yeti3dpro/

There you can download the original source as well as an editor. The code needed a bunch of work for the N64... the sprite and skin textures needed to be converted from BGR555 to RGBA5551 format, the model and level data need endian conversions, and I had to make some code changes like fixes for gcc 4.6.2, fixing player collision, allowing picking up items, doing damage to the player, adding strafing (which isn't part of the original code), and fixing printing messages.  To be clear, this is a PORT of Yeti3D Pro by Derek J. Evans. The base code is all his.

So what do you get? Yeti3D Pro has levels made of 64 by 64 square cells. Sounds limiting, but just check out some of the levels - they can be pretty large and complex. Yeti3D Pro goes beyond the original Yeti3D by adding slopes to floors and ceilings, as well as dynamic lighting - this allows much more realistic looking levels. Another addition to the Pro version is full support for MD2 format 3D models for more realistic objects and opponents. The rendering engine has been tremendously improved, allowing for more polygons to be rendered at a faster frame rate.

You can download my archive from here: Yeti3D-Pro N64 r1

The archive includes all source, and the N64 rom image (Yeti3D_Pro.z64) in the N64 directory. So what does the N64 rom give you? There are 33 levels - 32 loaded from the rom filesystem, and one embedded in the executable (normally all levels are embedded). You can pick up health bonuses, and "quads" which currently give you more ammo. You can shoot the creatures found in the levels, but if you do, they'll attack. Attacks do damage, as does lava.

So what is missing? The big thing missing is sound. I'm working on the sound, but am not sure it'll be ready by the deadline, hence this release. Also, the game ai is pretty stupid at the moment - the creatures just run around until you shoot them, then they attack. There are only two items you can pick up, and one weapon.

So is it a "full" game? Pretty much - you can explore levels to find two different items to collect (health and ammo), and you can fight with the creatures on the level (or avoid them). You'll have to search for the end of level teleporter - find the floating blue crystal to end the level and go to the next. This is more meant as a base from which to build a game. As such, I don't expect folks to rate it as high as an actual game. This is just another in my usual releases meant to help the homebrew scene by providing tools and code anyone can use for their own stuff.

controls

Code: [Select]

UP              move forward
DOWN            move backward
LEFT            turn left
RIGHT           turn right
LEFT SHOULDER   strafe left
RIGHT SHOULDER  strafe right
A               fire
B               jump
C-UP            look up
C-DOWN          look down
Z               run
START           menu

Notes:

You don't need a real N64 and flash cart to run this - it works just fine in MESS. It won't work on most other emulators since they tend to be high-level emulators geared towards old commercial games. That said, it works fine on a real N64 with the Myth cart. However, on real hardware, you need the memory expansion pack. The game as it is (with tons of embedded models and sprites and textures) needs over four megs of ram. If you were using this for your own game, you could easily trim that to fit within four megs. I don't consider needing the mempak a downside since it's something any real N64 user should have in the first place. If not, spend the $20 and get one!

You get about between 8 and 10 frame per second in most places, but really complex architecture or (more usually) lots of 3D objects/creatures can slow it down to 4 or 5 FPS. The rendering is all done by the CPU in software. I do plan to move as much of the rendering to the RSP as I can in future versions. But that will be after the sound is done.

The levels, sprites, and models are still in "PC" format so you can use the regular editor. I fix the models, sprites, and level data at run-time since I figure if someone actually uses this, they'll be using the editor on the PC and turning out "PC" formatted data.

EDIT: Now with screenshots! Taken using mess - click the image to go to the album on imgur where you can view closeups of each individual screenshot.

[theloon]

No sound?  Might I suggest some game names:

Silent Hell
Mute Effect
God of What?
Resident Earplug
Mimecraft
H.E.A.R.
Deafender

[ChillyWilly]

No sound?  Might I suggest some game names:

Silent Hell
Mute Effect
God of What?
Resident Earplug
Mimecraft
H.E.A.R.
Deafender

 

SOUNDS good to me!

I'm working on an RSP mixer right now so that sound won't take ANY cpu time. After that's working, I'll work on using the RSP for some of the video - the vector unit in the RSP looks good for the kind of pixel operations the renderer does. It would be nice to have the quad function on the RDP, but that's not available yet.

[theloon]

Wait, this is all in C?  N64 development in C?!?  Last time I looked C support was barely a wrapper for assembly.

Is there any chance for a version that is ready to makefile/build including the C compiler you use?

[ChillyWilly]

Wait, this is all in C?  N64 development in C?!?  Last time I looked C support was barely a wrapper for assembly.

Is there any chance for a version that is ready to makefile/build including the C compiler you use?

The project folder IS build-ready... as long as you have the compiler and sdk built and working, it just needs a "make" to build. The SDK is libdragon: http://www.dragonminded.com/n64dev/libdragon/

That includes the ability to build the toolchain, which is plain gcc. So you get regular C which you can use to do the entire game. No assembly needed. You build the toolchain first, use that to build libdragon, and then you're ready to build things like Yeti3D Pro.
 

I've got experimental C++ going, but it hasn't been added to the current version of libdragon yet.

What OS do you use? I use Xubuntu (Ubuntu with XFCE).

[theloon]

That's the catch with C compilers is setting up the libraries and compiler and environment.. ack!

I'm usually stuck on Windows XP - 7

Now that I look at it you're doing it right.  I just compared your archive with Robot Finds Kitten for the 7800 and he too has things set up like you.

I guess I should have asked where the wiki page to set up your C compiler and libraries is!

[ChillyWilly]

You SHOULD be able to set it up with cygwin. Depending on your PC, it might be easier to just run xubuntu in a virtual machine, then I could just send you an arc of my toolchain with the lib already built.

[10$man]

Wow, nice!
I used to mess around with Yeti3d on the GBA back a few years ago!
It inspired me to try to make a 3d engine for the Gameboy (classic), so far, I only got a cube rendered.

This is definitely a cool project though.

[ChillyWilly]

Wow, nice!
I used to mess around with Yeti3d on the GBA back a few years ago!
It inspired me to try to make a 3d engine for the Gameboy (classic), so far, I only got a cube rendered.

This is definitely a cool project though.

Doing similar 3D on a much lower system is a real challenge. You pretty much have to just use the knowledge gained and rewrite the thing from scratch based on what you CAN do on said system. Have you seen ProjectM on the A8? It's a ground-up Wolf3D clone. That sounds like what you were trying to do.

Yeti3D Pro is a pretty good match for the N64. Even without hardware rendering, the speed is playable. I find the dynamic lighting the most cool part... really adds to the atmosphere. Although Yeti3D Pro still has GBA defines in it, I don't see how it would ever compile for the GBA... not enough ram. The internal level map used in the game requires 256KB all by itself, and that's all the memory in the GBA. I ran into that while trying to get this to work on the 32X... not enough ram. Yeti3D Pro really needs at least 2MBytes, no matter how you trim things. This must be a real squeeze on the PS1.

I believe I remember reading the author saying this was more for older phones that didn't have hardware 3D. You know, those 100 to 300 MHz phones with 32 or 64 MB of ram, but no GPU. That GP2X also fits that description. I think most of the video demos of Yeti3D Pro are from the GP2X (or related handheld).

[theloon]

I was going to suggest using procedural generation for level maps but then I remembered that the decompressed info still takes up the same amount of space.. typed this comment anyway :p

[smealum]

yeti3D pro actually does run kind of well on the GBA (I say kind of because it's very impressive, but there are major framerate drops and it doesn't run in native resolution), you can try it here : http://gbadev.org/demos.php?showinfo=590
iirc, the GBA maps the cartridge to memory directly, so while you can't modify the data, you have read access to it as if it were RAM, which might explain how Yeti3D runs on the GBA. 

[ChillyWilly]

yeti3D pro actually does run kind of well on the GBA (I say kind of because it's very impressive, but there are major framerate drops and it doesn't run in native resolution), you can try it here : http://gbadev.org/demos.php?showinfo=590
iirc, the GBA maps the cartridge to memory directly, so while you can't modify the data, you have read access to it as if it were RAM, which might explain how Yeti3D runs on the GBA. 

No, it cannot be the Pro branch since that takes too much ram. It's probably the older branch where he started working towards the Pro branch, but it still ran on the GBA. Like I said, JUST THE MAP takes all the GBA ram, then there's a bunch of other things.

I use the 32X cart to hold read-only things just like the GBA on the older Yeti3D. It's the only way to get around the lack of ram. I would guess that demo you link has 3D models and slopes added, but everything else is still the older yeti base. I wish he had released more of the intermediate code bases - right now we have an early base and a later base.

Or... maybe someone makes a GBA cart with ram? I've seen NDS carts with extra ram - you need one with 16MB to run Quake2DS, for example. With more ram, running the Pro branch on the GBA should still work. That's really the only REAL issue with many games on the GBA or 32X - lack of ram.

[smealum]

No, it cannot be the Pro branch since that takes too much ram. It's probably the older branch where he started working towards the Pro branch, but it still ran on the GBA. Like I said, JUST THE MAP takes all the GBA ram, then there's a bunch of other things.

I use the 32X cart to hold read-only things just like the GBA on the older Yeti3D. It's the only way to get around the lack of ram. I would guess that demo you link has 3D models and slopes added, but everything else is still the older yeti base. I wish he had released more of the intermediate code bases - right now we have an early base and a later base.

Or... maybe someone makes a GBA cart with ram? I've seen NDS carts with extra ram - you need one with 16MB to run Quake2DS, for example. With more ram, running the Pro branch on the GBA should still work. That's really the only REAL issue with many games on the GBA or 32X - lack of ram.

Well sure I'm not saying the latest yeti3D pro version runs on the GBA, but since it includes tons of features not present in yeti3D GPL, I figured it made sense to call it yeti3D pro, even if it's an older version, especially since it's got similar content to your own demo :
vs

And as I said,  IIRC RAM isn't necessarily such a limiting factor on the GBA, since you can have direct access to everything on your cartridge. So if the map was static data, it wouldn't even have to be held in ram. So the current version of yeti3D pro would probably need heavy modifications, but considering that the only non static data would be stuff like entities and lighting, it might be possible for it to run.

(don't take my word for it, I haven't really done any work on the GBA so I'm not sure)

Anyway, your screenshots look really nice, good luck in the competition ! 

[ChillyWilly]

The map is a mix of static and dynamic fields. It's not cleanly split. That was one of the things I was trying on the 32X - split the map into fully static and dynamic parts so that the static parts could be left in the rom. It's a huge pain as everything references just the map, which means editing almost every file for references to THE map to change it to one of two maps. That's why I'd like to see earlier versions... I'd guess the original version of what became Pro had the map with dynamic fields only and a pointer to the static fields in ram. At some point in development, he probably got tired of the extra link and just copied all the data into the map, which ballooned the size to its current state.

EDIT: I played that GBA demo a bit... it's closer to the old version than it is to Pro. The levels are a bit simpler, there is only certain kinds of slopes (more like one kind of floor or ceiling tilt than a general slope), I didn't see any dynamic lighting... I noticed he called it Yeti3D V2, so it's clearly not yet to where he started calling it Yeti3D Pro.