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] 4 5 ... 15
Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 04:53:23 am »
It's been awhile since I've needed to convert any model. The bug is with the # of frames processed. I don't remember exactly (to process a base model with 62 animated frames, i'd have to command it to process 65 frames, after duplicating the last frame, for a total of 64 files--it might just be i have a misplaced expectation; its ok). When/if you do get back around to it, I'm sure you'll either notice or not notice because I was just using it wrong. Anyway, thank you again for making that model converter. Any tools you share mean a lot.

And, definitely use it over the jo engine converter, for now.

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 04:43:48 am »
The reason I'm using UV mapping is because when I originally tried to use per face images, Jo Map Editor complained about multiple texture files. It seems like the pipeline from object modelling to rendering in engine is not exactly covered in the documentation. If I ever figure this out, I may have to make a video just so there is some definitive guide to doing so.

To put it simply, it's incomplete.
I stopped using Jo Map Editor to convert models awhile ago. I never tried to use any textures with it, so what do I know? In any case it probably complained about multiple texture files because you've only got 512KB of video memory to work with.

I do hope to be helpful. Thank you for reading.

Check out this thread:
XL2's converter has some bugs, but once you do figure it out, it can be a big help. Or a big headache. I don't know, do you want both? You'll probably get both...

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 03:55:28 am »
I don't know what's going on. I recommend you start over from "demo - advanced 3D". I tried a few things, black screen, unending. Of course we all wish we knew what was wrong...
Another good starting point is a demo XL2 gave me.;topic=864.0;attach=121

A few things I noticed in the code that is going to cause problems in the future:

Code: [Select]
void move_cam(void)

Do not do this! These are not 3D functions, they change where the projection plane is. They do not navigate the camera in 3D space. Just don't change these values.

A good way to set display parameters. I first got this snippet from XL2.

Code: [Select]
void	initCamera(jo_camera * curCam)
(*curCam).viewpoint[X] = toFIXED(0.0);
(*curCam).viewpoint[Y] = toFIXED(0.0);
(*curCam).viewpoint[Z] = toFIXED(5.0);
(*curCam).z_angle = DEGtoANG(0.0);
(*curCam).target[X] = toFIXED(0.0);
(*curCam).target[Y] = toFIXED(0.0);
(*curCam).target[Z] = toFIXED(0.0);
slWindow(0, 0, JO_TV_WIDTH-1, JO_TV_HEIGHT-1, draw_distance, JO_TV_WIDTH_2, JO_TV_HEIGHT_2);
slPerspective(DEGtoANG(90)); //FOV

You don't need to set    slZdspLevel(7);   with that above snippet. slPerspective does that.

Code: [Select]
	int index;
for(index = 0; index < num_object; index++)

Can you explain that one? The whole game is already a loop, it isn't going to miss an object when it needs to render it. Unless this is some anachronism of you needing to display a hard-coded mesh. (that's probably it)

Also, 3D objects need to be pushed into a matrix, and then populated. Changing that doesn't fix your problem but it's likely part of it. (display_mesh_mesh needs to be part of a matrix)

Also, the saturn does not support texture coordinates. Thus, you can't texture map with UV. Texture mapping for the Saturn basically amounts to assigning a texture to a polygon then changing the texture until it looks right. If you have a large texture and want to span it over multiple polygons, you have to break that texture down manually into the pieces that will be assigned to their specific polygons.

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 02:27:32 am »
Compare your OBJs with this OBJ.

I did export your model in Blender then import it with the editor, and while I did not check the model, the header file seemed to check out.

Also, as a sanity check, see how your code handles this header file.

Here is a screenshot of my export params:

1 - The Saturn has texture warping. It's going to happen. Particularly, it's going to happen whenever a polygon has one of its vertices leave the edge of the screen. This is completely normal, and you shouldn't worry about it, because you can't fix it without polygon subdivision. Which you shouldn't worry about yet.

2 - Try using a .obj file instead of .dae. I've never used .dae but I know .objs import fine.

3 - That model is definitely too big. You never saw it because the render space is a FIXED-point value (16 bit whole number, 16 bit decimal). At >32768, you can't leave the render space for that so you were always inside the model. Additionally, all 4 vertices of every face were always off-camera so nothing could come into view anyway.

Another note - that you probably already know, but I'll say it anyway - SGL does perform backface culling within the same mesh based on its normals. There's nothing extra you have to do, as long as the data tables are arranged properly by XL2's model converter or the one in Jo Map Editor.

There's much hubbub about this practice because the way SGL does it is not always ideal, but the process of solving that one is being worked on in libyaul (or otherwise by our local hero, XL2). Otherwise, I don't know anything.

Free talk / Re: Happy New Year !
« on: January 08, 2019, 07:52:30 pm »
happy new year, good internet samaritan

About you / Re: Hello there...
« on: December 28, 2018, 09:05:50 pm »
nice to see interest.

the true difficulty of working in C for the Saturn is digging through SBL/SGL when you need something special :)

If a programming language supports the SH2 (Hitachi name) or J2 (Open-source name) processor as a build target / compiler target, you could theoretically write a program for the Saturn in that language, as the program target is the SH2's [it goes to their memory].

However, you can only practically use the C program language because SGL, SBL, and Jo Engine (as well as all other available extensions/snippets) for the Saturn are in C (as well as the process of making iso's set up for C). If you wanted to use another language, you would still ultimately have to go back to C to translate the hardware access functions back into a usable form (unless you wanted to find the Assembly function tables for everything but the SH2's/J2's.. which you still might need.

In other words, yes only C. And not even all of C, only some of it, and some C functions are done better by SBL or SGL functions (dividing numbers when decimal points are desired, for example, can work more desirably using FIXED data type with slDivFX). Jo Engine also has a number of handy shortcuts, look in math.h.

For more information on this, you can find SGL/SBL documentation around the net. I think some of it even on Jo website?

Ports require a lot of work because you need to translate the 3D, audio, drive access, you know all hardware functions of the game into things the Saturn understands. This is no trivial matter.

It's obviously best to start small and work your way up the ladder of hardware understanding. I wish you skill & patience.

Project announcement / Re: Sonic Z-Treme
« on: October 20, 2018, 05:50:11 am »
That's really cool. I am at least familiar with how levels are made via BSP via UnrealEd.

... that doesn't mean anything, but the ability to make levels in such a way is a large benefit.

Jo Engine Wish List / Re: Object library
« on: October 19, 2018, 09:32:28 pm »
Those are abstractions of creating sprites, defining a location, and so forth yes?

If so, you can create those yourself.

Here's an example of how that looks in 3D:

Code: [Select]
void	stuff2(Uint8 entity_number, Sint16 loc[XYZ]){
jo_3d_translate_matrix(loc[X], loc[Y], loc[Z]);
display_ztp(&entities[entityNumber], false);
To remove that, you set up a condition wherein it is included or not included in the runtime.

Of course you want things structured a little differently, but know this:
Much of your object data is the textures and model data itself, which is already contained and can be referenced and edited.
There are also jo_sprite and jo_vector data handlers that you can integrate into your ideal concept of "jo_object".

What I read below like "jo_create_object" and "jo_delete_object" are structured as if console commands to be used in runtime and run only once.
The "run only once part" complicates the structure of your code as what you are presently working with in jo engine is a giant loop.

You might also be confused by how to organize your matrix, but I'm sure you can figure that one out with trial and error.

Nova and Mednafen cannot be trusted. (Especially Nova!)
If it works correctly in Bizhawk, SSF, and Yabause, it probably also works correctly on real hardware.
I do not know what else to tell you.

How do other emulators behave? (Bizhawk and SSF)

And if it ever appears, it is clearly getting into memory.

Pages: 1 2 [3] 4 5 ... 15
SMF spam blocked by CleanTalk