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.

Messages - ponut64

Pages: [1] 2 3 ... 11
Project announcement / Re: Sonic Z-Treme
« on: August 14, 2018, 03:58:33 pm »
We'll see from/at SAGE.

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.
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?].

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:

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.

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.

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.

It is costly in all standards to use software rendering.

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]

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]

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.

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.

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;

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){
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];
    for (i = 0; i < currentPDATA->nbPoint*sizeof(POINT); i+= sizeof(int)) {
*src++; *nxt++;
    Uint8 *src2=currentModel->animation[animCtrl->currentKeyFrm]->cNorm;
    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++; *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);

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

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)

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.

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

Pages: [1] 2 3 ... 11
SMF spam blocked by CleanTalk