Messages

256

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.

257

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.

258

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.

259

Share your code / Re: 3D Map tool + FPS demo

« on: November 07, 2017, 01:50:42 am »

Using the vdp2 is quite hard. You could DMA sprites to the VDP2 NBG1, but you would be limited to not too big sprites and would need to clear the screen each frame. You would probably also have to store them in the main RAM, taking precious memory away.

I didn't update the FPS demo for a long while, so it's really dated now compared to what I have in Z-Treme (it gives me a speed boost of around 40% compared to what's in the FPS demo). The map converter is also old now compared to what I have in Z-treme.

I still plan to update it within the next few months.

260

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).

261

Project announcement / Re: Sonic Z-Treme

« on: November 03, 2017, 03:43:49 am »

0.034 was more stable, so I would suggest using that instead until I release 0.036 or 0.04 (If I nail the 3d implementation )

262

Jo Engine Wish List / Re: Drawing "billboard" sprites in 3D, sprite pre-scaling

« on: November 02, 2017, 03:30:53 am »

I second Null1024's demand for 2 points sprites scaled support.
SGL has the slPutSprite function, which allows the usage of the current matrix to know where the position is and scale it.
It displays a 2 point sprite (I don't know if there is a better function than slPutSprite in SGL).

You only need to change one line in the current jo_sprite_draw to make it work, with maybe some small corrections to be made.
But I would suggest removing a couple of lines to speed things up might be nice since you are just using the current projection matrix and as it is you need the centered_style_coordinates always at true.
I would recommand having High Speed Shrink always ON as well (HSSon after ECdis) as it speeds up the drawing at the cost of some precision, but since we are using 2 points sprites only to display things like rings or small bullets and other things like that, it doesn't matter that much if it's very precise.

Code: [Select]

void                    jo_sprite_draw(const int sprite_id, const jo_pos3D * const pos, const bool centered_style_coordinates)
{
#if JO_COMPILE_USING_SGL
    FIXED               sgl_pos[XYZS];
    SPR_ATTR            attr = SPR_ATTRIBUTE(0, No_Palet, No_Gouraud, CL32KRGB | ECdis, sprNoflip | FUNC_Sprite);

    sgl_pos[2] = JO_MULT_BY_65536(pos->z);
    sgl_pos[3] = __jo_sprite_attributes.fixed_scale;
    if (centered_style_coordinates)
    {
        sgl_pos[0] = JO_MULT_BY_65536(pos->x);
        sgl_pos[1] = JO_MULT_BY_65536(pos->y);
    }
    else
    {
        sgl_pos[0] = JO_MULT_BY_65536(pos->x - JO_TV_WIDTH_2 + JO_DIV_BY_2(__jo_sprite_def[sprite_id].width));
        sgl_pos[1] = JO_MULT_BY_65536(pos->y - JO_TV_HEIGHT_2 + JO_DIV_BY_2(__jo_sprite_def[sprite_id].height));
    }
    __jo_set_sprite_attributes(&attr, sprite_id);
   
    slPutSprite(sgl_pos, &attr, 0);   //was  slDispSprite(sgl_pos, &attr, 0);
#endif
}

 

263

Project announcement / Re: Sonic Z-Treme

« on: November 01, 2017, 10:05:53 pm »

0.35 is super glitchy, so I removed it. I'm working on a new 3d implementation (again!) for more speed. It might take a few more weeks.

264

General Jo Engine Help / Re: Graphics and memory managment

« on: October 30, 2017, 09:08:45 pm »

Yes you can : you can use the new jo engine cpu dma transfer function. That's how you can do your animations without storing all the frames in the 512 kb texture memory. You can also use paletted sprites (currently 8 bits only) to hold 2 times more textures. You should also use the vdp2 for background and foregrount elements since you have another 512 kb there and it's very powerful.

265

General Jo Engine Help / Re: A few questions about PCM functionality

« on: October 24, 2017, 03:52:48 pm »

Wouldn't MIDI be for music? Sadly I haven't played too much with audio yet so I don't know much about it, but I'll have to improve memory usage as RAM is limited!

266

General Jo Engine Help / Re: A few questions about PCM functionality

« on: October 24, 2017, 06:15:03 am »

For me too it's a huge issue as 44100 hz files are just filling my RAM. I still have room in LWRAM, but I have other plans for it. The audio files (only little sounds) take around 250 kb, which is ridiculus for the length. 22050 hz audio would make it half that, and 11025 hz would me it even better.

267

Jo Engine Wish List / Re: Reading binary files with pointers instead of returned char stream?

« on: October 21, 2017, 02:35:08 am »

Thanks to both of you. It seems to work OK (but I haven't tried on real hardware). Now returning to work on building a kd tree + PVS.

Me and Danny are also starting to look at the SCU DSP. Do you think it can be used for matrix transformation?
I know most people couldn't get anything out of it, but they were using SGL.
The way I see it would be to do matrix transformation on it and DMA the result in the z-sort buffer, but I'm not sure it's possible (with small meshes only, since the SCU DSP RAM is 256x32 bits, which isn't a problem for me)

268

Jo Engine Wish List / Re: Reading binary files with pointers instead of returned char stream?

« on: October 19, 2017, 02:51:42 am »

Thanks for the function, I'm using it already as I write palette data but I'm not using it (I tried to make 3d quads work with it by using the img_8_bits loading function, but it didn't go too well, so I'll have to write my own sprite loading function for 4 bits sprites textures).

Now, one more request (last one about this I hope) : instead of using a char for the buffer parameter, can you allow us to just put the memory address for direct loading?
I swapped the endianness on the PC side to support Saturn's endianness and I am using the jo_fs_read_next_bytes function to write directly to memory, which should speed up things nicely.
The only problem is that the compiler doesn't like this and throws warnings, which are annoying obviously, but otherwise it works fine.
So I'm not using a buffer at all, just straight to memory, and I think it would be nice that the function works this way right away (since I'm probably the only one using it at the moment, I don't think it will cause huge issues if you make the change on the existing function).
Thanks!

269

Project announcement / Re: Sonic Z-Treme

« on: October 17, 2017, 03:04:47 am »

As long as you don't say you did this game, there shouldn't be any issues
For me v.0.035 is buggy and I'm having loading issues.
Can you confirm that crystal frost loads fine and you're not having glitches?
If so just post it public right away.
I'm changing my loading mecanism for faster loading (pre-swap endianness and not using buffers) and will integrate paletted sprites for extra VDP2 effects on polygons (such as transparency)

270

Project announcement / Re: Sonic Z-Treme

« on: October 17, 2017, 02:27:15 am »

It's VDP2 transparency, which is easily supported by the Saturn. The problem is with vdp1 (polygons).