Messages

241

General Jo Engine Help / Re: Graphics and memory managment

« on: January 05, 2018, 03:57:43 am »

Here is the image converter app I created, enjoy!

http://forum.jo-engine.org/index.php?topic=855.msg1256#msg1256

242

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

243

Share your code / Re: Spreadsheet data analysis SS featured games UPDATED: 02-12-2017 60% Complete

« on: December 13, 2017, 10:26:21 pm »

Good job! Keep up your good work!

244

Project announcement / Re: Sonic Z-Treme

« on: December 11, 2017, 01:03:32 am »

Slowly, I'm almost rewriting everything.

245

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 */
}

246

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.

https://youtu.be/B4ro-a_aSdg

247

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)?
Thanks!

248

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.

249

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.

250

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.

251

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.

252

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.

253

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.

254

Project announcement / Re: Sonic Z-Treme

« on: November 09, 2017, 01:52:05 am »

I converted them to .obj and then to .ztm.

255

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!) :