Wanting to start a new project, and a few questions.

Post a topic about yourself to let others know your skills, hobbies, etc.
Post Reply
User avatar
ArthCarvalho
Active PSXDEV User
Active PSXDEV User
Posts: 45
Joined: Jan 29, 2016
I am a: Artist, Programmer
PlayStation Model: SCPH-103

Wanting to start a new project, and a few questions.

Post by ArthCarvalho » 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...)

HatMusic
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: May 29, 2014

Post by HatMusic » November 6th, 2019, 6:39 am

Can you tell me more about the Soul Reaver fog system? I'm not sure I understood your explanation.

For texture warping (for ground textures, anyway), Sheep Dog N' Wolf uses a technique which works really well. In that game, the basic ground is always gouraud shaded untextured polygons, but with patches of flat texture detail (like leaves or mud) and occasional vertical detail textures on edges (like flowers/grass or weeds). I imagine it subdivides polygons too, though. Lameguy64 might be able to help with that, as he's building a whole new SDK and rendering engine for the PSX (PSXNoobSDK and Project Scarlet (which he is porting to the new SDK)).
That's a pretty game - it even has little butterflies and birds flying around.

As for the rest of your questions, I would like to know too!

User avatar
ArthCarvalho
Active PSXDEV User
Active PSXDEV User
Posts: 45
Joined: Jan 29, 2016
I am a: Artist, Programmer
PlayStation Model: SCPH-103

Post by ArthCarvalho » November 6th, 2019, 9:22 pm

HatMusic wrote: November 6th, 2019, 6:39 am Can you tell me more about the Soul Reaver fog system? I'm not sure I understood your explanation.

For texture warping (for ground textures, anyway), Sheep Dog N' Wolf uses a technique which works really well. In that game, the basic ground is always gouraud shaded untextured polygons, but with patches of flat texture detail (like leaves or mud) and occasional vertical detail textures on edges (like flowers/grass or weeds). I imagine it subdivides polygons too, though. Lameguy64 might be able to help with that, as he's building a whole new SDK and rendering engine for the PSX (PSXNoobSDK and Project Scarlet (which he is porting to the new SDK)).
That's a pretty game - it even has little butterflies and birds flying around.

As for the rest of your questions, I would like to know too!
Using flat ground is a good way to avoid wrapping, but it also defines a lot the whole "feel" of the game. It works for more colorful (Caroony) graphics like Megaman Legends (which by the way, is the kind of graphics that holds well even to this today), but I'm looking for a little of that retro feel, so I don't mind a little warping here and there, but using without any kind of subdivision makes the warping too pronounced, so I need to figure out a way to do it anyway.

Now, for the Fog used in Soul Reaver, there are a bunch of ways to do this, but it is something like this:
You render a set of polygons without textures and only vertex colors: they range from black (area without fog) to the fog color you want.
Now you get these same polygons and render them again, now with textures and vertex colors, but you fade the vertex colors to black where the fog is and use semi-transparency (also known as blending, in this case, additive blending)

With this, you get textured polygons and they fade to the color of the fog.

The "base" untextured polygons would be like this:
With black being the areas without fog, and would interpolate according to the distance to the desired fog color:
Image
This would be the vertex colors of the cloned polygons, white being the area without fog (on the PS1 it woud be gray: RGB 128 128 128):
Image
When it is rendered with textures it would look like this:
Image
By setting this as additive blending you'll get this result:
Image

An optimization option for this is to set a "fog threshold" where polygons who are affected by below a certain percentage of fog are drawn normally (only the textured layer, without blending) and polygons that are 100% fog to be drawn only as untextured polygons.
This is quite taxing on the machine, as it not only renders twice the geometry for fog affected areas, but it also requires blending that reads from the framebuffer. But seeing there are comercial games with this (Soul Reaver being one of them) shows it is doable.

HatMusic
Curious PSXDEV User
Curious PSXDEV User
Posts: 17
Joined: May 29, 2014

Post by HatMusic » November 7th, 2019, 4:39 am

So it's sort of like how Gran Turismo and others draw shiny surfaces on cars? Cool beans.

User avatar
[C]oopeZz
BANNED
BANNED
Posts: 16
Joined: Feb 25, 2019
I am a: Electromechanic
Location: Czech republic

Post by [C]oopeZz » November 7th, 2019, 9:45 am

Wow, good luck ^^
[PC]
CPU: AMD Ryzen 5 1600X
GPU: NVIDIA GeForce GTX 1060 6GB
RAM: 16GB DDR4
MB: B450M Gaming Plus
HDD: 1TB Seagate Barracuda
SSD: 120GB Kingston
-----
[PS 1]
Model: SCPH-9002
Modchip: No
-----
[PS Classic]
Model: SCPH-1000R
Mod: BleemSync 1.2.0
Current limiter removed for USB port 2

User avatar
ArthCarvalho
Active PSXDEV User
Active PSXDEV User
Posts: 45
Joined: Jan 29, 2016
I am a: Artist, Programmer
PlayStation Model: SCPH-103

Post by ArthCarvalho » November 23rd, 2019, 4:11 am

Well, I broke through the first steps, and was able to code a small proof of concept with a "relative to camera" player movement and a camera behavior slightly similar to how the camera behaves in Zelda.
It's still rough, there are a lot of improvements, but I thought I wasn't going to be able to do it on the PS1 so I'm very satisfied.
Working with fixed point is slightly harder because there is no standardized fixed point math library available (that is optimized for the PlayStation CPU). Had to cobble together one by piecing functions from various sources. I'm learning MIPS Assembly, so I believe in the future at least I'll be able to optimize something out of this.

[BBvideo=560,315]https://www.youtube.com/watch?v=h_rO0rhUgIQ[/BBvideo]
(Link's model and that BGM from Zelda are placeholders of course)

I've completed a few milestones I set for my self:
  • Create a model format (Static) for backgrounds and blender exporter
  • Built up a basic fixed point math library needed for player movement (has code for sin/cos, arctan2 etc.)
  • SEQ Music playback
  • Basic player movement
  • Basic camera that responds to player movement
And the next steps are probably going to be the hardest:
  • Collision detection
  • Skeletal Animation

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » November 23rd, 2019, 11:32 am

That's actually really well made. There's a lot of potential there :clap
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
ArthCarvalho
Active PSXDEV User
Active PSXDEV User
Posts: 45
Joined: Jan 29, 2016
I am a: Artist, Programmer
PlayStation Model: SCPH-103

Post by ArthCarvalho » December 2nd, 2019, 7:26 pm

Implemented a few new things...
A debug menu so I can play around with things when I finally burn this to a disc to test on the real hardware, a distortion screen effect and ambient color for backgrounds.
[BBvideo=560,315]https://www.youtube.com/watch?v=Vfz5rVeg_Qg[/BBvideo]
Also the main thing is this code to face towards an arbitrary vector in the hierarchical animation.
It is very rough since I'm just creating a rotation matrix from a vector transformed back into the "bone" local space of the model, also it's not accurate, but should be good enough for this kind of stuff, I just need to transform said vector into local Euler rotations so I can interpolate and limit the movement so in the future characters using this won't break their necks when the player moves behind them.

I'll leave animation related stuff for later and now move onto Collision Detection, this is pretty much the final barrier for me. If I can get a collision detection system working that doesn't tank the game into 10fps then I probably be able to make something playable.

Edit:
Running on the real hardware:
[BBvideo=560,315]https://www.youtube.com/watch?v=NW6oKWDHTX8[/BBvideo]

It really feels like home on a CRT TV:
Image
Image

Xavi92
Verified
C Programming Expert
C Programming Expert
Posts: 161
Joined: Oct 06, 2012
PlayStation Model: SCPH-5502
Contact:

Post by Xavi92 » December 17th, 2019, 11:01 am

ArthCarvalho wrote:I'm just creating a rotation matrix from a vector transformed back into the "bone" local space of the model, also it's not accurate, but should be good enough for this kind of stuff, I just need to transform said vector into local Euler rotations[...]
Image

Seriously though, you're making a truly awesome work! Specially considering you have (AFAIK) no previous experience with the PS1. Sincerely, I wished I knew as much as you about 3D engines!

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » December 17th, 2019, 1:43 pm

That is insane! This engine has a lot of potential :)
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

rama3
Verified
/// PSXDEV | ELITE ///
/// PSXDEV | ELITE ///
Posts: 510
Joined: Apr 16, 2017

Post by rama3 » December 18th, 2019, 4:48 am

I like Link floating around in white boxers. Definitely should keep that as an easteregg or smth :p

Someone
Curious PSXDEV User
Curious PSXDEV User
Posts: 20
Joined: Aug 07, 2016

Post by Someone » December 22nd, 2019, 2:26 am

ArthCarvalho wrote: November 1st, 2019, 12:09 pm-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.
Not true. Look at game Small Soldiers, it uses texture window command for such scrolling. Also look at Armorines, it uses repeated texture in VRAM and just moves UV across it.

User avatar
ArthCarvalho
Active PSXDEV User
Active PSXDEV User
Posts: 45
Joined: Jan 29, 2016
I am a: Artist, Programmer
PlayStation Model: SCPH-103

Post by ArthCarvalho » December 22nd, 2019, 1:32 pm

Someone wrote: December 22nd, 2019, 2:26 am Not true. Look at game Small Soldiers, it uses texture window command for such scrolling. Also look at Armorines, it uses repeated texture in VRAM and just moves UV across it.
That's a good option, but why is it that so few games used texture window commands? It feels like the vast majority simply didn't bother with it at all. How much of a performance impact does it have on rendering?

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests