Messages

16

General discussion about the Sega Saturn / Re: Idea of UV mapping on the Saturn

« on: August 11, 2018, 10:49:05 pm »

More to the point, it's pre-processed; the image on the sphere is pretty much just a screenshot. You'll notice the heavy lag time before the ball comes into play after the game stops.

17

Share your code / Re: I burn my ISO on one CD, but it's don't run on my Saturn... :-(

« on: August 10, 2018, 05:25:50 am »

Is this a PAL or NTSC system?
Is it "Model 1" or "Model 2" system? What version is the CD drive board? [JVC, Hitachi, or Sanyo]
Preliminary tests indicate the engine is running into invalid memory ranges. You'll have to dig into the "jo_tga_loader" function and mandate that it always start at a specified memory address to use it the way you want to.
This, however, is not the explicit cause for your freeze.

Your functions are also out-of-order. my_gamepad calls functions that have yet to be defined. Move it above jo_main, but below all else.
In combination with memory range overflow, this might be the cause of the crash.

Another thing you should do is ensure jo_tga_loader will only be struck when it is incomplete. If jo_tga_loader is ever finished, it should not be called anymore, as it isn't meant to be used asynchronously. Jo engine might be tolerant of the current usage, but I would try to control it more strictly to prevent unseen memory shenanigans.

Of course, you may wonder: "We use jo_free_img to free the memory range specified for the background image. Why doesn't that work?"
Those are not meant to be used in conjunction with loading functions asynchronously. You must only free once, before the next image is loaded. This is probably the cause of the crash.

18

General discussion about the Sega Saturn / Re: Idea of UV mapping on the Saturn

« on: August 08, 2018, 12:56:10 am »

In what game?
Sonic R?
The extent of software rendering in that game is, IIRC, not an end-to-end pipeline. Certain stages are assisted via software rather than entirely software rendered.
A game that is software rendered on these consoles looks like the Saturn DOOM port, the HexXen Saturn/PS ports, and the Duke 3D playstation port. Compare said PS port of Duke 3D to the hardware-accelerated Duke 3D port that is on the Saturn. And in that way do also note: It also includes some software rendering assistance, as far as I have read from corvus.
You can't get real-time shading or fade-in / fade-out effects on VDP1 without such a thing.

In another way, the Saturn has two SH2s, so you can safely run the render pipeline on one of them without interrupting the program registers / task scheduler on the other. Which is what SGL does.
My point is that software rendering is massively slower than using VDP1 and VDP2 for everything you can use them for, even if it does mean using them in strictly unnecessary ways. Yet if you have the expertise, I do think you could schedule a system where triangles of a mesh are texture-mapped in software rather than on VDP1, but doing so would be a massive undertaking with regards to scheduling the program to ensure it both looks right and runs without interrupting the rest of the system (due to DMA time).

More to MY personal point of view on this matter, VDP1 is not fast enough to be invested in high-quality textures on every polygon alongside real-time shading. If that means all triangle polygons have to be untextured, GOOD! It saves performance and we don't have to be bothered with it!

Instead of throwing around conjecture like this, everyone would better use their time actually trying this out and determining if its worth the time. I haven't the time to prove what I am saying because folks around here have found ways to pre-distort the textures on triangles so they look more appropriate.

19

General discussion about the Sega Saturn / Re: Idea of UV mapping on the Saturn

« on: August 08, 2018, 12:14:46 am »

It is costly in all standards to use software rendering.

20

Share your code / Re: Monogame/HLSL Effect/Shader for Saturn-like graphics.

« on: August 04, 2018, 04:41:14 am »

I don't understand what's happening but you have my interest.
IIRC the Saturn graphics hardware has no Z-buffer anyway, perhaps ignore it then?

Question: What graphics API is this? [OGL/Vulkan/DX]
[my own research indicates: various, depending on build target]

21

General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.

« on: August 03, 2018, 07:50:26 pm »

As far as I gather, the transparent pixels consume cycles because they are present in the instruction for as long as any pixel would be until the next instruction.
The key to the end codes is to truncate the length of the instruction, not so much to reduce the computational intensity of that instruction.
It being based on filling the frame-buffer, it is timed with Vblank, so the computational intensity of what can be done by Vblank is something that you can more or less assume will never change, as it's always the same amount of time. Thus reducing the time spent on regions of the instruction is how you save performance in this case.
[I realize this is a very obvious series of statements, perhaps I shouldn't conjecture about things I don't understand]

Also, that's some good work on the pre-distortion, enderdude.
[If it wasn't clear, you grab the top-right vertice and drag it one box-size up]

22

General Jo Engine Help / Re: Making a 'corrected texture' on a triangle.

« on: August 03, 2018, 05:57:18 am »

This is the concept:
Take your square texture.
Take the bottom right vertice and move it to the same position as the bottom left vertice. Do not merge them.
Done.

You can do this in Adobe Photoshop.

So this texture...


What does this look like, undistorted?
It's this:


How do we pre-distort that .. when we want this:


... I don't know.

23

Share your code / Re: Model converter (.ZTP) -0.1 - WIP

« on: August 02, 2018, 03:02:51 am »

So variable interpolation was simpler than I expected. It's pretty coarse, but it works.

The struct is now like this:

Code: [Select]

typedef struct
{
	bool uniform;
	Uint8 arate[256];
    Uint16 currentFrm;
    Uint8 currentKeyFrm;
    Uint8 startFrm;
    Uint8 endFrm;
} animationControl;

Note arate, a 256 array of 8-bit values. The array size corresponds with the key frame data sizes.

For each frame of your animation area, if it is of non-uniform interpolation speed, you must define the arate for each key frame.

Code: [Select]

void	anim_defs(void)
{
	forward.uniform = false;
	forward.arate[0] = 1;
	forward.arate[1] = 4;
	forward.arate[2] = 1;
	forward.arate[3] = 1;
	forward.arate[4] = 4;
	forward.arate[5] = 1;
	forward.arate[6] = 1;
	forward.currentKeyFrm = 0;
	forward.startFrm = 1;
	forward.endFrm=7;
	
	left.uniform = false;
	left.arate[8] = 2;
	left.arate[9] = 1;
	left.arate[10] = 1;
	left.arate[11] = 2;
	left.currentKeyFrm = 8;
	left.startFrm = 8;
	left.endFrm = 11;
	
	right.uniform = false;
	right.arate[10] = 2;
	right.arate[11] = 1;
	right.arate[12] = 1;
	right.arate[13] = 2;
	right.currentKeyFrm = 10;
	right.startFrm = 10;
	right.endFrm = 13;
	
	idle.uniform = false;
	idle.arate[0] = 0;
	idle.currentKeyFrm = 8;
	idle.startFrm = 7;
	idle.endFrm = 7;
}

And here's a slightly changed animation code.

Code: [Select]

/**XL2 Animation Interpolation system with ANORM.h lookup table**/
#include "anorm.h"
void display_animated_model(animationControl * animCtrl, entity_t * currentModel, bool UseRealtimeGouraud)
{
	if(currentModel->nbMeshes < 1){
		return;
	}
	Uint8 ANIM_SIZE = 6;
	Uint8 ANIM_QUAL = 3;

    XPDATA * currentPDATA = currentModel->pol[0];

    /**Sets the animation data**/
///Variable interpolation set
if(animCtrl->uniform == false){
    animCtrl->currentFrm += animCtrl->arate[animCtrl->currentKeyFrm];
} else {
	animCtrl->currentFrm += 2;
}
///MATH: The below line increments the key-frame based on the current frame, which is incremented each frame by the arate.
///The arate in this case is 2. With an arate of 2, the current frame goes up twice for every frame of the game played...
///To compensate for this, we bitshift by 3 instead of 4 to increment the keyframe once every 30 iterations instead of once every 15 iterations.
///The ultimate control is the arate. XL2 set it up this way so it could be related to the game's frame-rate value, which at 30fps, is 2.
///It really does need to be this way or else the compression ratio does not work at all properly.
///This is, for all practical purposes, a fixed-function animation system with only 1 controllable variable of precise operation: the arate. (though creative souls could change the anim size variable)
   animCtrl->currentKeyFrm = (animCtrl->currentFrm>>3);  //should be >>currentModel->AnimInterpolation;
    if (animCtrl->currentKeyFrm >= animCtrl->endFrm)    {
        animCtrl->currentFrm -= (animCtrl->endFrm - animCtrl->startFrm)<<3; //<<currentModel->AnimInterpolation;
        animCtrl->currentKeyFrm = animCtrl->currentFrm>>3;  //>>currentModel->AnimInterpolation;
     } else if(animCtrl->currentKeyFrm < animCtrl->startFrm){
		animCtrl->currentKeyFrm = animCtrl->startFrm;
		animCtrl->currentFrm += (animCtrl->endFrm-animCtrl->startFrm)<<3;
	}

    Uint8 nextKeyFrm = animCtrl->currentKeyFrm+1;
    if (nextKeyFrm >= animCtrl->endFrm){
        nextKeyFrm = animCtrl->startFrm;
	} else if (nextKeyFrm <= animCtrl->startFrm){
        nextKeyFrm = animCtrl->startFrm;
	}
    compVert * curKeyFrame = (compVert*)currentModel->animation[animCtrl->currentKeyFrm]->cVert;
    compVert * nextKeyFrame = (compVert*)currentModel->animation[nextKeyFrm]->cVert;

	///Don't touch this!
	Uint32 compHelp = (animCtrl->currentFrm)-(animCtrl->currentKeyFrm<<3);
    /*if (nextKeyFrm>animCtrl->currentKeyFrm) compHelp = animCtrl->currentFrm-(animCtrl->currentKeyFrm<<3);
    else compHelp = animCtrl->currentFrm-(animCtrl->currentKeyFrm<<3);*/

    /**Uncompress the vertices and apply linear interpolation**/
    register Uint32	i;
    Sint32 *dst=currentPDATA->pntbl[0];
    Sint16 *src=curKeyFrame[0];
    Sint16 *nxt=nextKeyFrame[0];
	///Decompression
    for (i = 0; i < currentPDATA->nbPoint*sizeof(POINT); i+= sizeof(int)) {
		*dst++=(*src+(((*nxt-*src)*compHelp)>>ANIM_QUAL))<<ANIM_SIZE;
		*src++; *nxt++;
    }
    *dst=currentPDATA->pltbl[0].norm[0];
    Uint8 *src2=currentModel->animation[animCtrl->currentKeyFrm]->cNorm;
	///Interpolation
    for (i = 0; i < currentPDATA->nbPolygon; i++)    {
    /**Not 100% sure which technique is faster**/
        // currentPDATA->pltbl[i].norm[X]=ANORMS[*src2][X];
        // currentPDATA->pltbl[i].norm[Y]=ANORMS[*src2][Y];
        // currentPDATA->pltbl[i].norm[Z]=ANORMS[*src2++][Z];
        *dst++=ANORMS[*src2][X];
        *dst++=ANORMS[*src2][Y];
        *dst++=ANORMS[*src2++][Z];
        *dst++; *dst++;
    }
	jo_printf(0, 10, "(anim dat)");
	jo_printf(0, 11, "(%i)", dst);
	jo_printf(0, 12, "(%i)", src);
	jo_printf(0, 13, "(%i)", dst);
	
	jo_printf(0, 15, "(%i)", animCtrl->currentKeyFrm);
	jo_printf(0, 16, "(%i)", animCtrl->currentFrm);
	jo_printf(0, 17, "(%i)", animCtrl->startFrm);
	jo_printf(0, 18, "(%i)", animCtrl->endFrm);
	jo_printf(0, 19, "(%i)", compHelp);
    if (UseRealtimeGouraud) slPutPolygonX(currentPDATA, light);
    else slPutPolygon((PDATA*)currentPDATA);
}

http://www.mediafire.com/file/78rr5pc0zbvln52/proj_8118.zip/file

24

General Jo Engine Help / Re: Trouble with RLE compression for 4 Bits CLUT conversion

« on: July 31, 2018, 11:54:05 pm »

RLE: 2 is the correct factor of RLE in the converter.
In any case I use Paint.NET.

25

Project announcement / Re: Sonic Z-Treme

« on: July 31, 2018, 09:58:54 pm »

Check model scale/size if the normals are "acting up".
(go lower, or higher, see if issue persists)

26

General Jo Engine Help / Re: Texturing and 3d Animation Questions

« on: July 30, 2018, 07:15:45 am »

Look into XL2's binary model files and converter. You would probably want that to manage memory and also to map textures.
That is started by naming the materials in Blender and making a texture with the same name as the material. Polygons with the same material as that texture name will have that texture.
As far as how Jo engine does this, ATM, you scope through the header file and assign a texture to each polygon or you use jo engine feature to assign a texture to the entire mesh.

27

General discussion about the Sega Saturn / Re: My "tribute" to Sega Saturn.

« on: July 29, 2018, 11:00:00 pm »

I am glad to read estimates and comparisons between system hardware/software based on objective fact. And learn about new games!

28

Share your code / Re: Model converter (.ZTP) -0.1 - WIP

« on: July 28, 2018, 06:41:31 pm »

Change the data type of framerate to unsigned instead of signed (Uint instead of Sint).
However, you should be working with the binary file instead of the header files, which use a different function to animate.
I'm pretty close to being entirely done with PCM sound (which is big yay), so maybe in the next few days I can get my own version of the animate function out.
[Yes, I really want my own version, since there could be computational implications different from what XL2 makes and I just want to see what those end up being]

29

General Jo Engine Help / Re: compile.sh hangs while cleanup happens

« on: July 27, 2018, 05:16:53 am »

Likely something to do with the makefile?

30

Share your code / Re: Model converter (.ZTP) -0.1 - WIP

« on: July 26, 2018, 10:50:52 pm »

I’ve been trying to make the drill char blink by using shape keys, but you can see where the vertices of one texture move back inside while the other one moves out. I think this is because of the interpolation making the transformation between the two frames smooth, even though it’s not the intended result. I hope there might be a way to specify a ztp file to turn OFF the interpolation for certain animations.

The way you do this is by changing the animation function itself to be more robust in its parameters.
I haven't gotten around to it yet (stuck in PCM sound) and XL2 may have done it already but words.