Wanting to start a new project, and a few questions.
Posted: November 1st, 2019, 12:09 pm
Have been getting an urge to code things in low level lately, working as a web developer made me go crazy to come back and do something for older hardware. (High level languages like JavaScript are too boring)
The project I'm planning to do is a 3D action game, basically it's a Zelda-like clone.
(As a programmer, I could do it relatively easily using pure C and OpenGL/DirectX at least on PC, that is...)
In my experience with PS1 development up until now, the most I was able to accomplish was... uh... this:
https://www.youtube.com/watch?v=VpejG0nk7Q8
(The music is overlaid on the video, I didn't implement anything sound-related yet)
I did model loading, infinite scrolling backgrounds (the plain field there that moves) and movement with the analog stick.
After playing with this a little, a lot of work-related stuff started to show up and I had to abandon the project.
But now I'm relatively free and really want to make something at least that looks like an actual game.
I already have a good idea of what I need to implement right away, and the challenges I'm going to face (the known ones, because I'm 100% sure worse things are going to pop up)
-Collision detection / Collision response: AABB/plane intersection, rays, etc.
-A 3D model format that supports both object rotation and "Bone"-like animations for the PS1: I've read about it a little, and it seems that PS1 games don't use skeleton and weights, but it's pretty much various objects liked together and a few triangles that connect both of them.
-A 3D model format specific for collision maps: since it doesn't render it can use larger and less polygons, plus it doesn't need to be as detailed as the map, and allows arbitrary walls to wall off parts of the map the player is not supposed to go to.
-An animation system: for all the animated models that allow animation mixed with dynamic positioning rotation for effects such as looking at things (well, Tomb Raider does it, so it is definitely feasible on a PS1). This part here is interesting because one of the developers of the N64 Zeldas said that "it would not be possible on a CD-based system because Link had over 1000 different animations streamed from the cartridge. But it is well known that Crash was able to have vertex animation that is way more heavier storage wise, so I think this will be a fun challenge, plus, if anything, it can be made with basic animations without affecting too much of the gameplay elements, so those optimizations can be skipped or left for later in development.
-CLUT manager: for fog effects, with interpolation between two or three clut colors.
There's also the option of implementing a fog system like Soul Reaver does, where they render a non-textured polygon with the vertex colors below + fog, and then render a textured polygon with the fog using semi-transparency, which gives an effect very close to hardware fog like the N64 has, which can be pretty atmospheric, specially for dungeons.
-A system for texture animations/CLUT animations: Since you can't just scroll textures like the Nintendo64 does, Water, fire and other animations need to be animated manually in the VRAM.
-Day/Night sytem: Since this is a Zelda-like game, I thought about trying a day/night system like zelda does, and with that the fog also needs to change according to time. A day/night system is not that hard to do. You change the fog and sky color according to a table. Spyro shows that it is very possible to make skyboxes in PS1 games.
Additionally only objects are dynamically lit. The background is static shaded with vertex colors, said vertex colors can be updated in the background slowly as time progresses, and shouldn't be a problem. Also this can be skipped if not feasible.
-Quad subdivision: to remove affine transformations artifacts, specially since a Zelda-like game uses a more eye-level camera than most PS1 games.
-And other things that I still haven't thought about.
The biggest challenges here are the Collision, Model and Animations. (specifically the animation part, static models are easy enough).
I have a few questions regarding how to deal with a few things that are new to me, and other things that are specific to the hardware.
First, about fixed-point math. Coming from PC programming, I'm used to not need to worry about things like this at all.
Of course, dealing with this kind of stuff is part of the fun of programming for old hardware, but information is very scarce, as it is barely used today.
It is weird because GTE uses a bunch of different precision types, like 4.12 and the like. (which, you don't need to worry about when using floating point)
My question is mainly about how should I distribute those different precision types. For instance, what precision level is best for objects in a level? Should the XYZ position of every object in a level use 16.16, or just integers and leave fixed point for movement vectors and rotations? I know unit vectors are always 4.12, that's understandable. But apparently translation vectors are just a signed integer (32bit)?
And what is the best methods for collision detection/response? Specially on a integer based CPU.
I don't have any other means of testing my code besides burning CD-Rs and running in my modded PS-one, I have absolutely no debug hardware, and I fear the laser on my unit is going to give up soon (like the older one did), leaving me with no other way of testing my code on real hardware. I don't want to invest in something like a PSIO until I know I'll be able to move my project forward.
My idea is to test mostly on emulators, and eventually burn a disc to check everything. But I already ran into problems when running code that run fine on every emulator I tested, but caused problems on real hardware.
Which leads to the question, which emulators are the best for testing?
I already use these:
-NO$PSX (to debug)
-MEDNAFEN (most of the time)
-XEBRA (sometimes to check if it still working ok)
Anyway, I welcome suggestions and any ideas that you have on how I can implement most of these things.
I really want to be able to make something playable this time.
(Also, thinking about this, graphically, the N64 Zeldas are not really impressive, and were not particularly well optimized and had extremely poor performance. PS1 developers were able to push much more out of the hardware than Nintendo did in the N64 lifetime. The only ones who pushed the hardware were Rare (Banjo/Conker) and Factor 5 (Indiana Jones/Star Wars), so even if my game ends up running at 20fps it's still on target...)
The project I'm planning to do is a 3D action game, basically it's a Zelda-like clone.
(As a programmer, I could do it relatively easily using pure C and OpenGL/DirectX at least on PC, that is...)
In my experience with PS1 development up until now, the most I was able to accomplish was... uh... this:
https://www.youtube.com/watch?v=VpejG0nk7Q8
(The music is overlaid on the video, I didn't implement anything sound-related yet)
I did model loading, infinite scrolling backgrounds (the plain field there that moves) and movement with the analog stick.
After playing with this a little, a lot of work-related stuff started to show up and I had to abandon the project.
But now I'm relatively free and really want to make something at least that looks like an actual game.
I already have a good idea of what I need to implement right away, and the challenges I'm going to face (the known ones, because I'm 100% sure worse things are going to pop up)
-Collision detection / Collision response: AABB/plane intersection, rays, etc.
-A 3D model format that supports both object rotation and "Bone"-like animations for the PS1: I've read about it a little, and it seems that PS1 games don't use skeleton and weights, but it's pretty much various objects liked together and a few triangles that connect both of them.
-A 3D model format specific for collision maps: since it doesn't render it can use larger and less polygons, plus it doesn't need to be as detailed as the map, and allows arbitrary walls to wall off parts of the map the player is not supposed to go to.
-An animation system: for all the animated models that allow animation mixed with dynamic positioning rotation for effects such as looking at things (well, Tomb Raider does it, so it is definitely feasible on a PS1). This part here is interesting because one of the developers of the N64 Zeldas said that "it would not be possible on a CD-based system because Link had over 1000 different animations streamed from the cartridge. But it is well known that Crash was able to have vertex animation that is way more heavier storage wise, so I think this will be a fun challenge, plus, if anything, it can be made with basic animations without affecting too much of the gameplay elements, so those optimizations can be skipped or left for later in development.
-CLUT manager: for fog effects, with interpolation between two or three clut colors.
There's also the option of implementing a fog system like Soul Reaver does, where they render a non-textured polygon with the vertex colors below + fog, and then render a textured polygon with the fog using semi-transparency, which gives an effect very close to hardware fog like the N64 has, which can be pretty atmospheric, specially for dungeons.
-A system for texture animations/CLUT animations: Since you can't just scroll textures like the Nintendo64 does, Water, fire and other animations need to be animated manually in the VRAM.
-Day/Night sytem: Since this is a Zelda-like game, I thought about trying a day/night system like zelda does, and with that the fog also needs to change according to time. A day/night system is not that hard to do. You change the fog and sky color according to a table. Spyro shows that it is very possible to make skyboxes in PS1 games.
Additionally only objects are dynamically lit. The background is static shaded with vertex colors, said vertex colors can be updated in the background slowly as time progresses, and shouldn't be a problem. Also this can be skipped if not feasible.
-Quad subdivision: to remove affine transformations artifacts, specially since a Zelda-like game uses a more eye-level camera than most PS1 games.
-And other things that I still haven't thought about.
The biggest challenges here are the Collision, Model and Animations. (specifically the animation part, static models are easy enough).
I have a few questions regarding how to deal with a few things that are new to me, and other things that are specific to the hardware.
First, about fixed-point math. Coming from PC programming, I'm used to not need to worry about things like this at all.
Of course, dealing with this kind of stuff is part of the fun of programming for old hardware, but information is very scarce, as it is barely used today.
It is weird because GTE uses a bunch of different precision types, like 4.12 and the like. (which, you don't need to worry about when using floating point)
My question is mainly about how should I distribute those different precision types. For instance, what precision level is best for objects in a level? Should the XYZ position of every object in a level use 16.16, or just integers and leave fixed point for movement vectors and rotations? I know unit vectors are always 4.12, that's understandable. But apparently translation vectors are just a signed integer (32bit)?
And what is the best methods for collision detection/response? Specially on a integer based CPU.
I don't have any other means of testing my code besides burning CD-Rs and running in my modded PS-one, I have absolutely no debug hardware, and I fear the laser on my unit is going to give up soon (like the older one did), leaving me with no other way of testing my code on real hardware. I don't want to invest in something like a PSIO until I know I'll be able to move my project forward.
My idea is to test mostly on emulators, and eventually burn a disc to check everything. But I already ran into problems when running code that run fine on every emulator I tested, but caused problems on real hardware.
Which leads to the question, which emulators are the best for testing?
I already use these:
-NO$PSX (to debug)
-MEDNAFEN (most of the time)
-XEBRA (sometimes to check if it still working ok)
Anyway, I welcome suggestions and any ideas that you have on how I can implement most of these things.
I really want to be able to make something playable this time.
(Also, thinking about this, graphically, the N64 Zeldas are not really impressive, and were not particularly well optimized and had extremely poor performance. PS1 developers were able to push much more out of the hardware than Nintendo did in the N64 lifetime. The only ones who pushed the hardware were Rare (Banjo/Conker) and Factor 5 (Indiana Jones/Star Wars), so even if my game ends up running at 20fps it's still on target...)