Recent Posts

Pages: 1 [2] 3 4 ... 10
11
General Jo Engine Help / Re: Clipping planes and SGL?
« Last post by XL2 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
12
General Jo Engine Help / Netlink Support?
« Last post by itsstillthinking1999 on November 25, 2017, 08:35:44 pm »
I know its a really long shot but do you think down the road that jo engine could support the Netlink? I know its almost impossible as (to my knowledge) there is little to no documentation on coding the Netlink (outside of a few bits of code iv found on forums) was just wondering
13
General Jo Engine Help / Clipping planes and SGL?
« Last post by XL2 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!
14
Free talk / Re: Some New Sonic 32x/Mars/Xtreme Assets?
« Last post by SaturnTeam on November 23, 2017, 04:04:18 am »
Very cool!
15
General Jo Engine Help / Re: Graphics and memory managment
« Last post by XL2 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.
16
General Jo Engine Help / Re: Graphics and memory managment
« Last post by b1tsh1ft3r on November 20, 2017, 02:20:39 am »
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.

Is there perhaps a way to utilize the VDP2 RAM for storage of graphics while still letting the VDP1 Access these graphics somehow? or due to hardware design is this impossible?
17
General Jo Engine Help / Re: Graphics and memory managment
« Last post by XL2 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.
18
General Jo Engine Help / Re: Graphics and memory managment
« Last post by b1tsh1ft3r on November 18, 2017, 02:31:39 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.

Perhaps I'm missing something or the documentation is out of date here? Are there any good examples showing how to utilize the vdp2 for basic functionality such as you have described? (Setting background and foreground elements for display). Id like to try to utilize this for the MAP that is draw on screen and any UI stuff as well.
19
General Jo Engine Help / Re: Graphics and memory managment
« Last post by XL2 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.
20
General Jo Engine Help / Re: Graphics and memory managment
« Last post by Mr. Potatobadger on November 17, 2017, 04:29:25 am »
I'm a bit late to the punch here, but I highly recommend using palettes graphics. It's limited to 256 colors I'm pretty sure, but that's realistically more than enough, and it saves a ton of memory. However, at the moment, there's not really a good way to convert images into the format without writing a simple script

I plan on making a fully fledged tool eventually than can convert images into the paletted format, and also help you manage the palette registers.
Pages: 1 [2] 3 4 ... 10
SMF spam blocked by CleanTalk