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 ... 7
Project announcement / Re: Sonic Z-Treme
« on: December 11, 2017, 01:03:32 am »
Slowly, I'm almost rewriting everything.

General Jo Engine Help / Re: Clipping planes and SGL?
« on: November 28, 2017, 03:34:46 am »
I'm doing well with my monologue, so here is a way to have multiple windows if anyone is interrested.
Sadly, I don't think there is a way to disable Z sort within SGL, so the draw command gets sorted according to the distance, which means that it can't really work well unless you create your own rendering code
(which I guess could be done within SGL, but it would be a bit of a pain).

Code: [Select]
SPRITE user_win;
void SET_USER_CLIP(FIXED drawPriority, Sint16 XA, Sint16 YA, Sint16 XC, Sint16 YC)
    user_win.CTRL = FUNC_UserClip;
    user_win.XA = XA;  /*Top left pixel*/
    user_win.YA = YA; /*Top left pixel*/
    user_win.XC = XC; /*Bottom right pixel*/
    user_win.YC = YC; /*Bottom right pixel*/
    slSetSprite(&user_win, drawPriority); /* slSetSprite allows you to manually set the draw commands, so you could do anything with it...if there is a way to bypass the Z-sort */

General Jo Engine Help / Re: Clipping planes and SGL?
« on: November 26, 2017, 07:22:30 pm »
It will be easier to understand with an example. I made a quick video with Quake (with buggy OpenGL rendering) to show what I mean by using clipping planes for occlusion clipping (it helps the GPU only, not the CPU). You can also look under the VDP1 commands in Yabause to see that they keep using User clipping for each quad plane.

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 Jo Engine Help / Re: Graphics and memory managment
« on: November 20, 2017, 12:09:07 pm »
You can use the color RAM (4 KB), other than that I don't think you really can. You might be able to store things in VDP2 RAM and just read them, but I'm not sure it's possible and it would probably not be very efficient anyway.

General Jo Engine Help / Re: Graphics and memory managment
« on: November 18, 2017, 08:25:17 pm »
Right now Jo Engine doesn't support much the VDP2, so you would have to use SGL functions directly for everything except NBG0/1.
I'm not myself really good with the VDP2 as it's quite complicated, but it's really overpowered compared to the VDP1.
You can take a look at my old FPS demo or Dany's FPS/VDP2 demo to see how to use it.

General Jo Engine Help / Re: Graphics and memory managment
« on: November 17, 2017, 07:07:50 am »
No need, I'm already working on it for 4 bits CLUT and/or CRAM. You will need to preprocess your images (like on Gimp, you convert it to a 16 colors palette but save it as 32 bits RGB image). Of course, the CRAM is limited to 2048 colors, so the CLUT is more useful for most situations.

General Jo Engine Help / Re: Can't Get Jo_VDP2 to Work Properly
« on: November 16, 2017, 03:13:45 am »
Nobody says it's impossible, it's just a pain. You only have a 256 kb draw framebuffer and a 256 kb display framebuffer, so if you do the maths you will figure that it's impossible to use 16 bits data.

General Jo Engine Help / Re: Can't Get Jo_VDP2 to Work Properly
« on: November 16, 2017, 01:19:04 am »
480i resolution works by using 8 bits color data instead of 16 bits when you write to the framebuffer. You also need to coordinate the NBG0 and NBG1 so that they display the same thing, with one line offset. You also cannot use gouraud shading with it. It's just a pain and it's not worth it. You can try 352x480 instead, which, while half the horizontal resolution, comes at no cost except it's interlaced instead of progressive.

Project announcement / Re: Sonic Z-Treme
« on: November 11, 2017, 04:36:25 am »
It doesn't support yet, but you can use the SGL/SBL functions directly.

Project announcement / Re: Sonic Z-Treme
« on: November 09, 2017, 01:52:05 am »
I converted them to .obj and then to .ztm.

Project announcement / Re: Sonic Z-Treme
« on: November 08, 2017, 11:31:54 pm »
I'm rebuilding the 3d implementation and reworking on the collision detection code.
It might take a while.

I'm using Saturn Quake levels to stress test the engine, but since I haven't updated the FPS demo, it gives some weird results like this (I should add a shotgun and turn Sonic into Shadow and just call it Shadow Z-Treme, I'm sure that would be a wonderful idea!) : 

Project announcement / Re: Sonic Z-Treme
« on: November 08, 2017, 12:12:05 am »
Sorry, but I'm not looking for help at the moment and don't want to use other people's models.
The stage is from Project AXSX, that Andrew75 recreated after Sonic X-Treme's maps.

Project announcement / Re: Sonic Z-Treme
« on: November 07, 2017, 11:19:29 pm »
For the acceleration, I played with different settings and found it better to have a bit faster acceleration, which makes turning in 3d easier.
For the jump, I'm using the same value as classic games. The only difference is that the camera tilts as you jump.
For the slowdowns, I mentionned it before, I'm fully rewriting my 3d implementation for stable 60 fps.
I did the demo for Retro Barcelona in 3 days, the engine wasn't fully ready.
For other caracters, I'm not considering it atm.

For you waiting for the engine to be ready, I don't think I understand what you mean.

If you mean Sonic Z-Treme engine, I won't be making it public. But I might update the fps demo.

If you meant Jo engine, Johannes is working on a new implementation, but you can fully use SGL at the moment.

Project announcement / Re: Sonic Z-Treme
« on: November 07, 2017, 08:54:29 pm »
I don't know what you mean about the speed. If you mean the momentum, it's normal, there is friction but the engine keeps your speed.
The single slow jump could be terrible and make the game feel like you are under water.
So I won't do it.
For your point 3, the game is not finished, but adding levels isn't a priority since I'm busy working on my engine.

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