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
1
Yes, I would suggest you to start with 2d, it's much easier.

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

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



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


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

6
Weird, I never noticed that, but I remember reading that a scale of 1 will create a sprite 1 pixel larger. Try, for the scale, 65535 (or toFIXED(0.99999)) instead of 65536 (toFIXED(1.0)).

7
Project announcement / Re: Sonic Z-Treme
« on: October 20, 2018, 02:29:35 am »
So I got the BSP tree, portal generation and PVS all working.
Using a BSP is really a game changer, it's 10000% better than any previous solutions I used.
The only cost is extra geometry after splitting and a requirement that the levels need to be "closed off".

I would be possibly to use an octree for rendering and a BSP for collision/line of sight/raytracing, but so far I really like the BSP tree and it's perfect for corridor shooters.

Here are screenshots (in OpenGL, but I try to micmic the way the Saturn renders everything, with no texture coordinates and per vertex lighting).

Thanks to the BSP tree, adding lighting took only 1 hour or so.
It's just that great.
Since I am now using a PVS, I won't need the smooth fade-in/out anymore as I won't have a draw distance limit, so I can use RGB 4 bpp and gouraud shading on everything with no issues...so colored lighting works perfectly.


8
Project announcement / Re: Sonic Z-Treme
« on: September 30, 2018, 03:29:08 pm »
I already create quads, but sometimes it's impossible (like the area next to the flowers).
My solution will be to flag these objects as entities instead to avoid subdividing the map.
It should lead to very few subdivisions.
I also have a scoring system where subdivisions are to be avoided when selecting splitting planes.
About open maps, it's a huge concern and the portals might not even work.
I don't care that much since I want to focus on my fps game instead, so maps such as Quake maps should work fine.
But it's still a long way to go before I can test it on real hardware.

9
Project announcement / Re: Sonic Z-Treme
« on: September 28, 2018, 03:42:17 pm »
Here is a shot of Jade Gully in OpenGL (PC, for testing) after the BSP subdivision.
I just simulate the Saturn behaviour in OpenGL for faster testing.
I'm using a solid leaf bsp tree from the MrGamemaker famous bsp tutorial.

You can see, just like Saturn Quake and Saturn Duke Nukem 3D, how it creates some issues with textures because of the lack of texture coordinates.
The way around this is to declare some quads as entities instead of parts of the map to avoid diagonal subdivisions.
Some maps just don't work with it, such as Super Mario 64's peach castle.

I still have no portals and pvs, so I don't know if the maps that currently work will still work after, but it should help reducing the overdraw and speed up collision detection a lot, maybe allowing proper collision detection against the map for ennemies too.

10
Project announcement / Re: Sonic Z-Treme
« on: September 11, 2018, 02:14:32 am »
Quake maps do work with OKish draw distance, but have a very high poly count and vertices count. Still, 30 fps with Sonic and some 920 drawn polygons on screen isn't too bad considering all the overdraw.
I made some little progress on the bsp tree, but there are many problems to solve as nothing found online mentions quads or small polygons, so it might take a while to make it all work.

11
Project announcement / Re: Sonic Z-Treme
« on: September 06, 2018, 12:05:07 am »
Yeah, the Pal version was a quick workaround, so if you play at 60 hrz the framerate counter will report wrong values, so it always play slow.
As for the slowdown, at 50 fps it's expected, but at 25 fps, it shouldn't happen as far as I know.
Maybe a 1 frame dip?
I would need to see it, but if a polygon is covering the whole screen it's possible.

12
Project announcement / Re: Sonic Z-Treme
« on: August 31, 2018, 05:58:27 pm »
Well, I already have the Sonic icon from prototype 718, I just didn't want to add another sprite onscreen as I feared it might slow things down a little.
As for Sage, the reaction has been mixed, if not negative overall, so for now I decided to just focus on the FPS game.

13
I didn't use that in the Sage demo.

14
Project announcement / Re: Sonic Z-Treme
« on: August 26, 2018, 07:37:56 pm »
Yeah, it seems to work.
Metal Sonic is also transparent with the background layer, so it impacts its color as well.

15
Project announcement / Re: Sonic Z-Treme
« on: August 26, 2018, 06:55:45 pm »
The red gouraud works in Yabause, but the green bug doesn't work.
Metal Sonic is supposed to be yellow/gold when he's invincible or picks up rings.
If he's green, it doesn't work well.

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