Show Posts
1
Cool. Don't be afraid to ring us if you're confused about something.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Project announcement / Re: Sonic Z-Treme
« on: September 11, 2018, 04:18:34 am »
That is incredible; encroaching the limit of the system and still getting performance.
3
Project announcement / Re: what p64 does
« on: September 07, 2018, 08:43:36 am »
In stumbling about with true box-to-box collision detection (rather than only points), I stumbled on an alternate way to test a point against a normal.
It's helpful to share this, because it's basically 16-bit.
If you're wondering what else I would use, its separating axis theorem, which while simple to explain is much more verbose in code so I'll not go into that much more.
It's helpful to share this, because it's basically 16-bit.
Code: [Select]
Sint32 pt_col_plane(Sint16 planept[XYZ], Sint16 ptoffset[XYZ], Sint16 normal[XYZ], Sint16 offset[XYZ])
{
//Using a NORMAL OF A PLANE which is also a POINT ON THE PLANE and checking IF A POINT IS ON THAT PLANE
//the REAL POSITION of the normal, which is also a POINT ON THE PLANE, needs an actual position. WE FIND IT HERE.
Sint16 realNormal[XYZ] = {normal[X] - offset[X], normal[Y] - offset[Y], normal[Z] - offset[Z]};
Sint16 realpt[XYZ] = {planept[X] + ptoffset[X], planept[Y] + ptoffset[Y], planept[Z] + ptoffset[Z]};
//the DIFFERENCE between a POSSIBLE POINT ON THE PLANE, and a KNOWN POINT ON THE PLANE, must use the REAL POSITION of the NORMAL POINT.
Sint16 pNn[XYZ] = {realNormal[X] - realpt[X], realNormal[Y] - realpt[Y], realNormal[Z] - realpt[Z]};
//The NORMAL of the plane has NO REAL POSITION. it is FROM ORIGIN. We use the normal here.
//If the dot product here is zero, the point lies on the plane.
//The dot product being negative or positive can be used to determine whether the point has passed the plane.
Sint32 dot;
dot = vectori_dot(pNn, normal);
return dot;
}
If you're wondering what else I would use, its separating axis theorem, which while simple to explain is much more verbose in code so I'll not go into that much more.
4
Project announcement / Re: what p64 does
« on: September 06, 2018, 02:20:16 am »
1. I've never developed software before.
2. I've never programmed in the C language before. I did have some training courses on C# and C++ in Microsoft Visual Studio, but this did not output an executable.
3. I've never made development tools before. As I see it this is the true mark of a game development programmer. XL2 and Jo made the development tools.
4. I have had experience working in Unreal Engine, Torque, CryEngine, and TRIBES before as either making simple mods or making maps. Never finished anything but relatively simple maps.
5. My 3D modelling experience comes from making 3D printed objects, such as detailed figurines or mechanical objects. Like, for instance, an entire computer case.
That is a vastly different field because there one is required to make a manifold object. Video games carry no such requirement and often non-manifold objects consume less polygons.
6. As far as what game to make, my philosophy is what I can program is what should define what I can and will make.
Following that, I am going to do testing as far as I can until I feel as if I have programmed enough mechanics to make a satisfactory video game.
7. I work slowly.
2. I've never programmed in the C language before. I did have some training courses on C# and C++ in Microsoft Visual Studio, but this did not output an executable.
3. I've never made development tools before. As I see it this is the true mark of a game development programmer. XL2 and Jo made the development tools.
4. I have had experience working in Unreal Engine, Torque, CryEngine, and TRIBES before as either making simple mods or making maps. Never finished anything but relatively simple maps.
5. My 3D modelling experience comes from making 3D printed objects, such as detailed figurines or mechanical objects. Like, for instance, an entire computer case.
That is a vastly different field because there one is required to make a manifold object. Video games carry no such requirement and often non-manifold objects consume less polygons.
6. As far as what game to make, my philosophy is what I can program is what should define what I can and will make.
Following that, I am going to do testing as far as I can until I feel as if I have programmed enough mechanics to make a satisfactory video game.
7. I work slowly.
5
Project announcement / Re: what p64 does
« on: September 02, 2018, 06:05:41 am »
early physics?
https://youtu.be/cYPa7l0XfPo
https://youtu.be/cYPa7l0XfPo
6
Project announcement / Re: Sonic Z-Treme
« on: September 01, 2018, 01:25:18 am »
If people are stupid enough not to figure out that you can just bind the D-pad controls to an analog stick (or actually just use analog control), then perhaps you don't want them to like your game anyway.
Besides, I have a high opinion of the Saturn's D-pad for 3D games. It isn't anywhere near as bad as a PlayStation D-pad, and its better than most modern D-pads. It's one downfall is diagonal inputs aren't perfect.
(I realize just about nobody is actually using a Saturn controller for the game)
Besides, I have a high opinion of the Saturn's D-pad for 3D games. It isn't anywhere near as bad as a PlayStation D-pad, and its better than most modern D-pads. It's one downfall is diagonal inputs aren't perfect.
(I realize just about nobody is actually using a Saturn controller for the game)
7
Project announcement / Re: Sonic Z-Treme
« on: August 23, 2018, 09:35:46 am »
Great stuff !
I imagine the fisheye effect might have a small effect on texture warping? If the projection plane is not reduced in size and is merely closer to the camera, the vertices would have a little more space to go off camera before they started injecting you with LSD.
I imagine the fisheye effect might have a small effect on texture warping? If the projection plane is not reduced in size and is merely closer to the camera, the vertices would have a little more space to go off camera before they started injecting you with LSD.
8
Project announcement / Re: what p64 does
« on: August 21, 2018, 04:23:46 pm »
There was never any delay.. it was just the capture device being the garbage it is... 
https://youtu.be/0TOLTnLY5YE
https://youtu.be/0TOLTnLY5YE
9
Project announcement / what p64 does
« on: August 20, 2018, 09:22:52 pm »
So I'll start a thread, I guess, instead of spamming the help forum 
https://youtu.be/Y3nbalLUi0k
Anyone got clues about delayed audio? Might the B-Bus be saturated, causing a command delay?
If anyone wants to build/look at the code, here it is:
http://www.mediafire.com/file/9d3draeitk98ot0/proj_82018.zip/file
And yes, most of my posts are going to be about problems, as is typical...
https://youtu.be/Y3nbalLUi0k
Anyone got clues about delayed audio? Might the B-Bus be saturated, causing a command delay?
If anyone wants to build/look at the code, here it is:
http://www.mediafire.com/file/9d3draeitk98ot0/proj_82018.zip/file
And yes, most of my posts are going to be about problems, as is typical...
10
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« on: August 19, 2018, 05:18:59 am »The mesh effect looked ok on crt with composite, which is what people used back then, so it just made sense to use that instead of decreasing your framerate.That depends on the region, here in Europe we all used RGB since the scart cable came with the console.
I did not know that.
In which case, you've got pixel-perfect display...
11
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« on: August 17, 2018, 05:32:52 am »You mentioned the fm towns marty 3D sphere which gave me an idea but then I looked it up on youtube and it was nothing like my idea.
The idea is to use a normal VDP2 layer with small premade tiles and a CPU can decide how to composite the tiles to recreate what looks like any shadows.
The VDP1 draws arbitrary lines from the left line to the right using a greedy algorithm which causes pixels to be overdrawn. This avoids PS1-like gaps but causes the moire pattern with transparency. The other thing that causes the moire pattern was demonstrated well in one of Jon Burton's Sonic R videos. So unless each line is perfectly vertical or horizontal it'll overdraw causing transparency to be bollocks. This applies to skewed and rotated quads, not just perspective corrected quads.
One of the things you might have heard is that CRTs and composite video blurs the dithering enough to be a convincing shadow just drawing a dithered black oval over the ground. I didn't understand just how effective this was until I saw this composite capture of Z-treme on youtube: https://youtu.be/x7cW9wgIW00?t=50
Anyways you can tell how, back in the day, a team on a deadline scraping for ounces of power on a not quite adequate for 3D system would just draw an oval and be done with it.
I think one of the major issues with performance is that we're using an incredibly old jack-of-all-trades graphics library instead of tightly focused custom routines. Unlike a more straightforward graphics system, the saturn's really hard to write efficient graphic routines or even wrap your head around especially the memory scheduling. If two chips try to access the same memory chip in the same cycle, one of them will be halted until it gets access. This can basically throw away many cycles of work the saturn would otherwise be able to accomplish.
Anyways we got some interesting ideas floating around.
I can't blame anyone for being oblivious to this if you hadn't actually played on real Saturn hardware, but:
- The Saturn's AV / composite / yellow cable video signal is among the best (as far as that type is concerned).
- And yes, 100%, the typical transparency effect of blanking out half the pixels works pretty much flawlessly over this signal type. As far as I am concerned, the Saturn is meant to be used this way, and it would be nice if emulators included an image filter for it.
- S-Video, the near-neighbor display type to AV/yellow plug, is also good on the Saturn - in fact it's pretty much pixel perfect, which means the transparency effect is no longer convincing.
12
General discussion about the Sega Saturn / Re: Transparent Shading on The Saturn
« on: August 16, 2018, 01:26:48 am »
There are a few possibilities.
- They did not conceptualize the shadows as polygons, whether or not they actually were.
- Development for the system never got to the point where such a thing was conceived (remember, it was premier on the market for far less time than the PS1 and N64)
- Developers of the period hadn't a grasp of perspective correction well enough to understand that any method short of absolutely correct perspective correction has its applications compared to other methods. In other words, the Saturn doesn't have to use affine texture mapping, and the PS1 is worse for it, so the thought would be counter-intuitive.
- Developers were concerned with contextual overdraw, wherein interrupting the Saturn's perspective correction meant a part of the entire polygon pipeline, which could have drastic effects on the numbers of polygon's rendered if anything went wrong. (Most critically, because the texture warping on the Saturn is more or less because non-visible vertices are no longer calculated)
- Most likely, some developers of the time actually did do this, and we just don't know.
- They did not conceptualize the shadows as polygons, whether or not they actually were.
- Development for the system never got to the point where such a thing was conceived (remember, it was premier on the market for far less time than the PS1 and N64)
- Developers of the period hadn't a grasp of perspective correction well enough to understand that any method short of absolutely correct perspective correction has its applications compared to other methods. In other words, the Saturn doesn't have to use affine texture mapping, and the PS1 is worse for it, so the thought would be counter-intuitive.
- Developers were concerned with contextual overdraw, wherein interrupting the Saturn's perspective correction meant a part of the entire polygon pipeline, which could have drastic effects on the numbers of polygon's rendered if anything went wrong. (Most critically, because the texture warping on the Saturn is more or less because non-visible vertices are no longer calculated)
- Most likely, some developers of the time actually did do this, and we just don't know.
13
Project announcement / Re: Sonic Z-Treme
« on: August 14, 2018, 03:58:33 pm »
We'll see from/at SAGE.
14
General discussion about the Sega Saturn / Re: Idea of UV mapping on the Saturn
« on: August 12, 2018, 10:42:28 am »Well, how do other systems like the Jaguar pull this off at a better framerate? Is it because it has a higher bandwidth, or...? This is more of asking if we can remake Supercross 3d on the Sega Saturn.
The Jaguar might do it because it has less data to handle in a more compressed format in a more unified memory access structure.
Heavily segmented memory [on the Saturn] has its advantages but speed definitely is not one of them.
Now, we wonder: How, on the Saturn, would we do this?
I imagine it would involve use of one of VDP2's rotating background layers and a lot of memory copies, possibly even compression, or culling of certain assets from the memory copy to a TGA / bitmap format that VDP2 understands.
In other words:
Stream frame-buffer of VDP1 to a work area where it can be processed to a bitmap format and re-pasted to VDP2 RBG0 area, line-by-line (line being a chunk of the stream).
You can then move, scale, and rotate this effective re-projection wherever you like in 3D space.
Problems:
1. Extraordinarily busy on DMAs, cannot happen in concurrence with music streams, file system access, or SCU DSP access.
2. Quite slow, I don't foresee it working beyond 10 FPS.
3. Effectively limits the scene complexity to what can fit into RBG0 data area [130KB?].
15
Share your code / Re: I burn my ISO on one CD, but it's don't run on my Saturn... :-(
« on: August 12, 2018, 10:22:04 am »
That's very odd, I don't patch my ISOs and I don't need to enable pseudo saturn support, yet I can get things to boot in Pseudo Saturn just peachy.
Try adding this to your makefile:
JO_PSEUDO_SATURN_KAI_SUPPORT = 1
Try adding this to your makefile:
JO_PSEUDO_SATURN_KAI_SUPPORT = 1
SMF spam blocked by CleanTalk