Recent Posts

Pages: [1] 2 3 ... 10
1
Free talk / Jon Burton's breakdown of how Sonic R uses Saturn hardware
« Last post by Cement Man on September 21, 2018, 09:10:18 pm »
https://www.youtube.com/watch?v=RvRG_v8XpC0
I've always liked how Jon's videos make use of a ton of visual diagrams, a lot of these concepts are easier to grasp once they're mapped out into physical space. And though he only briefly touches on it, he says he'll go more into the SCU/DSP at a later point. Not sure if he'll really go that in-depth on it once the time comes but it should be an interesting watch at least.
2
About you / Re: aye
« Last post by SaturnTeam on September 20, 2018, 04:16:39 pm »
Welcome. Good luck!
3
About you / Re: aye
« Last post by ponut64 on September 14, 2018, 11:39:11 pm »
Cool. Don't be afraid to ring us if you're confused about something.
4
About you / aye
« Last post by Cement Man on September 14, 2018, 11:27:34 pm »
Happened across jo-engine on Sega-16 a couple weeks back and gave it a try out of curiosity. I don't have any prior experience with C coding, but after looking at the sample projects and the various bits of documentation hosted here everything seemed to click. Now I'm hooked.

I've always been interested in classic consoles but this is the first time I've had the opportunity to make something for one. It's pretty fun learning about the system architecture and the basics of managing assets in memory. And who knows, maybe I'll have something to show for it soon!
5
Project announcement / Re: Sonic Z-Treme
« Last post by corvusd on September 13, 2018, 11:50:51 am »
Quote from: XL2 on September 11, 2018, 02:14:32 am
Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.
I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.

Again great job XL2!

It is getting closer and closer to the nearly 1300 of Sonic-R at 30FPS. Definitely, you are putting more and more to the limit the possibilities of the DSP (transformation and lighting) of the two SH2, along with the management of calls to the VDP1 and VRAM of VDP1 and sound system. Not to mention physics, collisions or AI. That is to say all that traffic by BUS-B passing through the SCU. Amazing!

I am increasingly aware that this is one of the keys to the REAL optimization of the SS. In fact, in his reflection with PSX, this is also part of the key to his good performance. And having a Profile system made it really easy to expose all the bottlenecks in an engine or program.

Courage and thanks again! :)
6
Project announcement / Re: Sonic Z-Treme
« Last post by ponut64 on September 11, 2018, 04:18:34 am »
That is incredible; encroaching the limit of the system and still getting performance.
7
Project announcement / Re: Sonic Z-Treme
« Last post by XL2 on September 11, 2018, 02:14:32 am »
Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.
I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.
8
Share your code / Re: I burn my ISO on one CD, but it's don't run on my Saturn... :-(
« Last post by hbeira on September 08, 2018, 04:36:02 pm »
Quote from: XL2 on August 12, 2018, 07:38:41 pm
If your pseudo Saturn has ram, it will crash with Jo Engine becauseJo engine tries to allocate memory to a non-existant adress.
Use the workaround in the makefile or change the adress of the ram to the correct values.

Thanks for your answer, but I fix it and told how below... ;-)

Quote from: ponut64 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

Hey, I put this parameter and works! :-D
And I also put sound now using the parameter "JO_COMPILE_WITH_AUDIO_MODULE = 1"! :-)
Thanks a lot ponut64! Case solved! ;-)
9
Project announcement / Re: what p64 does
« Last post by ponut64 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.

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.
10
Project announcement / Re: what p64 does
« Last post by ponut64 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.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk