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.

Topics - XL2

Pages: [1]
Share your code / Model converter (.ZTP) -0.1 - WIP
« on: May 29, 2018, 05:51:36 am »
Here is my model converter (and source code) with my custom binary file format I made for my Sonic Z-Treme Engine (ZTP for Z-Treme Polygons).

The code is bad, I just quickly coded this and didn't spend much time cleaning up or removing all the globals.
I will revisit the code and try to add precalculated lightning and per vertex animation support. (done 2018-06-10)
I also added a demo I originaly made for our friend Virtua skimmer.
I would like to ditch OBJ files for DAE, but it's quite hard to implement so I might stick with OBJ for now.

New in version 0.05 : I rotated all the quads 180 degrees and flipped the normals so that the textures are in the proper direction (it was just an annoying issue that didn't cause problems). Updated the demo to add a few features. If you just want to use the converter, update your model loader c file in the ZT folder else you will get alignement issues (the sprites are now in ZTI format).

New in version 0.10 : Animation support! The tool can read a chain of OBJ files and do vertex animation (similar to Quake 2 MD2 format) with interpolation. The normals are also compressed. The demo's animation is bad simply because my own animation is bad, so don't mind it!

Share your code / 4 bits per pixel image converter app
« on: January 05, 2018, 03:46:21 am »
Here is an image converter app (.TGA files only) that will convert the images to both c source code and binary file in a 4 bits per pixel format. The app is super simple to use : put it in your image folder, launch it and just type de filename without the extension. It will produce 2 files.

I've also included a demo to use it both for 16 Colors Lookup Table sprites (VDP1) and 16 Colors Bank (VDP2 Color RAM). The demo loads one sprite from c code and two from binary files. It displays one sprite using CRAM and two using CLUT. It's using JO Engine in a ghetto fashion as 4 bpp isn't supported, so let me know if it creates issues with your apps.

Using 4 bits per pixel sprites helps reducing the VRAM usage while also easily allowing you to use advanced VDP2 effects.

I did it quickly and didn't do much testing, let me know if it doesn't work well!

EDIT : Added a 4 bytes buffer to allow space for the data pointer

General Jo Engine Help / Clipping planes and SGL?
« on: November 25, 2017, 06:32:41 pm »
Sgl has the slWindow function which allows you to select a user clipping plane and local coordinates. It's perfect to allow you to do split screen or not draw where your HUD is, as an example.
But SGL limits you to 2 windows max per draw call, probably for memory reasons.
Of course, it probably also have some impact on the cpu.
I want to set up up to 32 user clipping planes to try something for occlusion culling similar to what the Slavedriver engine did.
I can't seem to find where (or if it's even possible within SGL) I can change the max value or just put a user plane without using the slWindow function.
Is there a way to change this within SGL? Or another function I missed?
If not, where is the window data stored in memory (Before writing to the polygon buffer)?

General discussion about the Sega Saturn / Sega Basic Library 6.0
« on: November 06, 2017, 03:16:05 am »
I think it's fair to say that SBL was really overlooked (except for some functions added in SGL as well).

But it is really interesting in that it includes the source code for everything it does.
It includes a sprite (polygon) library (under SPR), with processing using the SCU DSP for matrix transformation.
It's probably slower than SGL overall, but since the source code is included, I think it's very interesting.

Has anyone ever given it a good look?

I haven't found any demos for it.

The 3d part seems more complete than SGL even if it was slower in the end, so I think it's a good starting point.

Things like "inbetween polygons" fix the issue of duplicated vertices after a map subdivision (octree, bsp, grid, etc.), while just making use of the SCU DSP at all is something SGL didn't even bother doing (unlike the high-end games like Burning Rangers, Quake and Sonic R using it).

General Jo Engine Help / 30 FPS?
« on: August 29, 2017, 08:07:12 pm »
It seems like we can't change the framerate in the makefile.
Like : JO_FRAMERATE = 2  has no effect at all.
Also, by changing the value directly in the Conf.h file, I experience crashes when there are too many polygons on screen, which never happens at 60 FPS for some reasons, so I'm not sure if it's not fully implemented or I'm missing something.

On a sidenote, related to what Null1024 mentionned about Jo Engine 9.0 potentially breaking some stuff, it seems that the exect on slave function doesn't work anymore as it should (it used to work in Sonic Z-Treme, but I had to remove it since it didn't execute the functions after upgrading.
I tested the Shooter demo (which also use the slave) and it's also broken, which further proves issues with the slave functions.

I managed to build my custom binary file format and read it on the Saturn, so I can display a mesh loaded from a binary file on the CD.

My concern now is that I'm using the jo_fs_read_file, which returns a char stream, which takes memory while I'm loading everything to the right place.
It's not a huge problem while loading small images and sound files, but for a map taking 1 MB, it just won't be doable (unless I'm mistaken and got it all wrong).

Is there a way, in Jo Engine, to just use a pointer to read the file and return each time only what you need (like 8, 16, 24 or 32 bits from a start pointer)?
If not, can it be added in the next version?

Share your code / 3D Map tool + FPS demo
« on: July 21, 2017, 08:57:49 pm »
Hi all,

I wrote a little tool to convert a level's polygons into bounding boxes (axis-aligned).
It merges the bounding boxes (BB) with their neighbour to reduce the amount of boxes.
It also calculates the slopes on one axis (x or z), but it doesn't generate the heigth masks yet (on my to do list).
It will be complicated to explain as I didn't add an example (on my to do list), so read carefuly and don't hesitate if you have questions.

Ok, now for the explanations (I'll try to explain, but I hope you guys will understand)

The idea is like this : you use a function similar to the Jo_intersect, but add the z axis... or just do 2 jo_intersect and replace the x with the z value for the second function.
Do 2 or 3 collision checks (x/z and y, or x and z and y - I suggest you go for 3)

If the collision mask value is -1, then just use it as is : you have a collision and just stop the movement on that direction.

If the mask is 0 or higher, then you just do a lookup in an array of values. The arrays I use are only 2 dimensions (because of memory constraints), but you could do 3 dimensions arrays as well for hills and other shapes.

Example : You know you have a slope if the rotation value on the x-axis isn't 0. So you look for a mask.
As an example, for a 45 degrees slope on the x-axis, your slopeRXangle will be 45 (or -45 depending on the direction).
So you look for the heigth mask returned by the function, and you look it up with your current Z position (not x since the axis of rotation is on the x axis - look for z as you go up or down on the slope), which will return a heigth value.

So let's say your relative Z position to the current BB is 100, and the BB has a length of 200.
Look at the array at position 100 (your z position minus the BB minimum z position), which will return a heigth value.

Just look for that value added to the minimum Y value of the bounding box to see if you have a collision (like, the minimum Y of the BB being -200, Y length being 200, and the heigth mask returns 100, so you look to see if you currently have a collision for an object with Y values ranging from -100 to 0)
Do another intersect check with your current Y value, if there is a hit, return it, else there is no collision.

This way, you can have smooth slopes with very little CPU usage. An it works for all 3 axis collision checks.
I need to improve my code to better merge the BB together and improve memory usage and CPU usage.
If you have a slope with side walls (looking "out" of the slope), you will hit an invisible wall as it won't merge them and it will cover your slope.
Just remove these walls for now and only keep the "ground" part (you might have to manualy ajust the heigth as well in the resulting file)
I didn't do much testing, so there might still be bugs I haven't found.

I'll also share my collision code at a later date, but right now I'm pretty much rewriting many parts of it so it's far from complete.

Hope this helps someone creating a 3D game!

EDIT : I added another version of the collision tool (still not good enough, it's buggy with slopes)
EDIT 2 : Added a function to write using Danny's code, but it's not 100% complete (WIP). Also got rid of the need to link to SGL.h, if it's causing issues make sure you tell me as I didn't test properly. I also quickly coded a .Obj exporter to Danny's code, but I didn't test it. Some stuff is wrong for sure and it might not work with all .Obj formatting, I will have to spend more time on this.
EDIT 3 : Added reading .OBJ files and binary file output. The FPS demo now uses the binary file format to load maps. I will add more features to the binary format.
EDIT 4 : Many bug fixed such as unaligned read/write, issues with multiple meshes. The .OBJ to binary seems to work fine now, tell me if you have issues. I also added basic view frustum culling to the FPS demo, put a HUD using Jo Engine functions (causes issues with other VDP2 functions, just uncomment other lines to revert to the RBG0 plane), removed the gouraud shading depth (made the game way too slow on real Saturn).

EDIT (2017-08-16) : Upgraded to Jo Engine 9.0 (make sure you upgrade also). I also fixed the memory allocation, so you should be able to load much bigger files now (try map 3 to see).

EDIT (2017-08-25) : You can now write textures directly in the binary file. The map program will read TGA textures (uncompressed only) and write them. Also added auto-subdivision of the map for culling, you just need to specify how many "cuts" you want (there is a bug that will sometimes "lose" polygons, so just try different values for "cuts" (x, y, z axis) if one setting doesn't work well). I also changed the FPS demo's collision code to reduce CPU usage.

Jo Engine Wish List / 3D mesh drawing and collision detection?
« on: April 28, 2017, 07:11:23 pm »

While working on a 3D collision detection function, I noticed that it didn't make sense (at least on the CPU) trying to read through all the polygons of a mesh in a loop, only to do 80% of the same work just seconds later to draw these polygons.  It seems like it's wasting ressources. My alternative right now is to hardcode very simple bounding boxes, but it's not as accurate and it creates problems when you consider matrix translations, where the box doesn't follow unless you also code it with a function (like a moving platform). Would it be possible to add a function that does both operations at the same time (while reading a polygon to send it to the vdp1, you also look for a collision with the coordinates you passed while calling the function)? Like, while you are looping through the polygons of a mesh to calculate the vertices and send them to the framebuffer, you also look for a collision with the current caracter's bounding box? Would it be helpful to reduce CPU use?
I hope I'm making sense!
Thanks again!

Project announcement / Sonic Z-Treme
« on: March 31, 2017, 01:58:46 am »

Here is my Sonic X-Treme remake project on Sega Saturn, running on real hardware :

v.0.071 :

Older version, ran at 60 fps on real hardware :
v.0.034 running on SSF :

Pages: [1]
SMF spam blocked by CleanTalk