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 - XL2

Pages: [1] 2 3 ... 24
Project announcement / Re: Sonic Z-Treme
« on: March 04, 2019, 03:09:59 am »
 Well, I got really fed up of the Sonic fans nitpicking and complaining nonstop either because it's too much like Sonic X-Treme or not enough (kind of comments I received : "hey moron, Sonic X-Treme used sprites, why are you using an ugly 3d model? Lol").
Or : "why aren't you porting Sonic Mania instead? Do I have to do it myself?".
Its just a really toxic community full of entitled kids, its better that I cancel this project to focus on something I find more interesting and challenging.

Not being stuck with Sonic X-Treme levels and design also allows me to push the hardware much more.
1300 drawn polygons at 20 fps ftw.
And Im still far from done optimizing everything.

Project announcement / Re: Sonic Z-Treme
« on: March 03, 2019, 07:25:42 am »
I'm not planning to put more time on it.

Project announcement / Re: Sonic Z-Treme
« on: February 07, 2019, 05:18:56 pm »
 Thanks. Sadly, no name yet as Im working on the engine, but I have the general plot and gameplay in mind.
It will be similar to Quake in style (but for gameplay I will have to chose between 2 types) and I aim for a fully 3d world (including enemies).
I will focus on the engine for the next few months, but it's a much more complex engine than in Sonic Z-Treme, with also much improved graphics.
This is an older version (I've since improved the framerate), which was also glitchy (weird dancing verts), with improper collision (the rotating star thing), no gameplay, etc.
But it gives you an idea of the engine's complexity and major improvements in lighting.

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 05:06:07 am »
Ah, yes, it was because of improper rounding I guess or something like take. I always use 1, but indeed it's a bug. Anyway, I won't update it anytime soon, but if I do I will add an OpenGL preview to see the results before trying it on the Saturn each time.
I do that now with my bsp compiler and it makes testing way more efficient than booting an emulator each time.
Also getting rid of the normals in SGL would be a really great thing.

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 04:50:45 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 is old and 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...

What bug?
I might revisit it later to precalculate the lighting and - hopefully - auto generate a LOD model.

Jo Map Editor / Re: Trouble with 3D Objects
« on: January 16, 2019, 04:48:42 am »
Just use my model converter, it even supports animations, allows realtime light, writes to binary and I released the source code.

As for zdsplevel, it's actually the near clipping level. Set it to 3, which makes it 1/8 your screen distance (which you can set with slscreendist and slPerspective - both do the same, one is the fixed distance, the other is your fov....which just changes the screen distance in fact.
Important thing, because it took me 3 days to properly write a fristum culling function using the geometric approach and using the fov as a way to calculate my frustum planes, until I noticed that sgl doesn't even have any kind of real projection matrix.

For your first question, if you look at some pdata headers, like those generated by Jo engine map editor or my own model converters, you will be able to change the attributes there. I don't recommand the current technique you are using to create models as this means for a simple cube you need to transform 24 vertices instead of just 8.

For your second question, do something like slZdsplevel(7);
That is your near plane of your frustum,  where the value is screenDist/(1<<7) . So if you set it to 1, that means if your screen distance is 250, objects near 125 will get clipped.
The screen distance is exactly the same thing as your FOV, so you can just set your FOV instead for simplicity.

Super interesting read. Keep up the good work!

Project announcement / Re: Sonic Z-Treme
« on: December 27, 2018, 09:22:12 pm »
I'm slowly moving away from Z-Treme toward the fps game, but here is a shot of the game on real hardware with 64x64 textures and gouraud shading while still hitting 30 fps (thanks to the pvs mainly).

Project announcement / Re: Sonic Z-Treme
« on: December 22, 2018, 07:15:07 am »
The source code isn't public.
As for the latest demo, it's here :

Yes, I would suggest you to start with 2d, it's much easier.

I would suggest you to start small, porting such a game would require a ton of work.

Ok, so I got a technique similar to Burning Rangers working.
I'm doing like BR, letting the VDP1 rasterize the sprites, SCU DMA the frame buffer to work RAM, then SCU DMA it to VDP2 VRAM, but instead of swapping the frame buffers or clearing it, I'm actualy using an offscreen area of the frame buffer.
So I don't have that 16 ms latency that BR had (well, it's my understanding from reading the VDP1 technical manual), so the game can still hit 60 fps in some areas (there is an impact on framerate, but lower than what BR did).
I had to work around SGL to get these working as, obviously, SGL never planned the hardware to be used in such a way.

If anyone is wondering how to do it :
1) Set your NBG0 or NBG1 layer to bitmap, 16 bits, scale x up by 2.2, y by 2.
2) Modify your system clip command to allow a range from 0 to 511 for the x value. No need to modify y.
3) Each frame, use a local coordinate of 432, 56, write a custom draw command and use a scaled sprite (8x1, no preclipping (faster this way), using a VDP2 palette value of 0 with no transparent pixels). Leave if in vram if you aren't using SGL. Also use a clipping window (352 to 511, and 0 to 111)

4) For each loop in your game's logic, start by DMAing the frame buffer array to the NBG0/1 VRAM (I use bank A0) with a for loop (like y=0; y<112; y++) and send the array in work ram line by line using SCU direct DMA.

5) Write - using custom draw commands - sprites or polygons that you will need to scale them (multiply) by x:0.454545 and y:0.5 in screen space coordinates to an offscreen area. Either use SGL's windows (far) for the transparent sprites, or just send them far in your drawing list to make sure they get drawn first and, more importantly, make sure they are affected by the correct local coordinates command.

6) Some time before vblank, DMA the frame buffer to work ram using again a loop to skip the lines and data. If you want to be safe, you can use the VDP1 registers to make sure you got past all transparent objects before DMAing the data. It will pause the drawing, so be warned! Transfer only what you need and ASAP.

7) Vblank, go back to point 4.

Of course, it won't solve the sorting issues since your transparent objects will be on top of everything, so you can use a low-quality model of your avatar using again mask values (0) and send them to the offscreen area, sorting everything with the current draw commands. You would also need to either send polygons masking the walls and all to the offscreen area or use a more fancy no-overdraw technique (such as portals, BSP, etc.).

I spent some time writing a proper software rasterizer.
The full-software mode doesn't work correctly yet, but the line rasterizer works pretty well (you calculate the edges and then send them to be rendered as lines for each scan line).
It does create a few issues :
-The edges overlap, which leads to overdraw (solution will be to have some kind of active edges and clip them against each other).
-It creates many lines (like 800 for a 12 triangles cube), which should be reduced with the active edges clipping and by allowing the lines to be rendered vertically as well depending on the height/width ratio. Another solution would be to use polylines with a depth of 2 pixels (so each line covers 2 scanlines, so one polygon - with other techniques - takes maximum 112 polylines for a size of 224 pixels).
-It is more CPU intensive than just sending the data to hardware as is.

While the Burning Rangers technique seems very nice, it's also quite hard to pull off and it's probably quite slow.
But its "worst" case scenario will be much faster than my worst case scenario for sure.
Another idea I might try is to use scaled sprites instead of lines and play with the RAM addresses. But it will have some weird distortion for sure.

Anyway, this whole technique could be useful for games such as racing games or for one effect (like a window) in a game.

Project announcement / Re: Sonic Z-Treme
« on: November 14, 2018, 02:54:00 pm »
Well, I'm not working on Sonic Z-Treme anymore, while I put very little time on the fps project. It should take a few months before I have something to show on Saturn.

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