Messages

16

Share your code / VDP2 3D Planes

« on: April 23, 2017, 12:45:42 am »

Hi friends, I have used the SGL directly to test the VDP2 3D planes with the objective of helping XL2 with his 3D sonic project.
The problem with this is  that its using the SGL directly and that it might screw up with the memory allocation of the JO-engine somehow, maybe this can also be done with the pseudo Mode7?
Johannes if this is possible could you provide a similar example to the one I'm sharing with the Mode7?

17

Project announcement / Re: 3D Sonic demo

« on: April 17, 2017, 10:16:55 am »

I'm glad my code was helpful
I have downloaded your project and will take a look at it during the week to help you out.
I'm also working on a method for drawing the 3d environment for my first person shooter game, I have been researching about binary space partitioning, quadtrees, octrees and portals to see what will be most useful.
Once I have something nice to show I will share it because surely it will be reusable on almost everything that needs a 3d environment 

18

Project announcement / Re: 3D Sonic demo

« on: April 15, 2017, 10:00:25 pm »

Here is in attachment an old presentation from a Sega Workshop from 95 that should help understand how the CPUs and VPUs work together. If you want I could also take a look at your source code and give you a hand.

19

Project announcement / Re: 3D Sonic demo

« on: April 13, 2017, 10:10:30 am »

Your demo is very nice!
I specially like the way you used a 3d model instead of a sprite for the main character .

20

Jo-Engine release / Re: Release 7.0

« on: April 13, 2017, 09:46:28 am »

That has also happened to me before and rebooting solved the issue, sometimes the Win32 memory management fails to allocate memory for Cygwin for some unknown reason 

21

Jo-Engine release / Re: Release 7.0

« on: April 12, 2017, 09:16:33 pm »

The video playback feature is great, congratulations on that!
What software did you use to convert the video to the Cinepak format?
By the way, thanks for adding my little bit of contribution in there

22

Share your code / Re: Dual SH2 usage example

« on: April 12, 2017, 04:14:49 pm »

Thanks  I hope this information will be useful form someone!
I have done parallel programming with POSIX threads and always wondered how that was done on the Saturn.
I have read in several places that the bus being shared was a big disadvantage because the ram can not be accessed at the same time, however this is the case for most architectures, that's why there are several levels of CPU cache to deal with concurrent access and speed things up.

The Saturn is not entirely crippled in this regard, its not like one CPU really has to wait for the other all the time because both of them have 4KB of local cache.
After researching the documentation and the forums for the correct way to use the slave CPU I decided to make a simple test program that had concurrent access to the ram (although not the same addresses).
By splitting an array in two and process a half on each CPU we have a test case for this scenario. This is a very academical example that might not demonstrate real world usage, there is also the question of accuracy of the emulator on emulating shared bus access and the reliability of using clock ticks to measure time. However if we can thrust these measurements the results seem very positive, in the test program using the two CPUs resulted in practically taking half the time to do the same thing! I will burn a CD this weekend and I'm hopping the same thing happens on a real Saturn.

It is also important to mention that even if this proves to be true that does not mean it is easy to parallelise everything, not all algorithms can be parallelised and synchronizing both CPU's makes a big impact on performance, if it is necessary to constantly access the same variable by both CPUS we will have to do a lot of busy waiting, burning CPU time and wasting bus bandwidth.
The parallelization should be done in a way that both CPUs do most of the work on their local memory only having to synchronize the work on the end, basically following the Fork-Join model.

I'm sorry guys, this post is getting really long , I'm going to mention just a couple more things I forgot on my firts post:
- My test program works fine on SSF but not on Yabause, I'm not sure if it has to do with Yabause not emulating some things correctly but I will verify this on a real Saturn soon.
- There are some other limitations you should take into account while using the slave CPU, I will just copy paste the part that is most relevant about this from the SGL FAQ text file where I got it from:

2-5 Cautions When Using the slSlaveFunc Function

Make sure that the functions executed by the slSlaveFunc do not overwrite the
master CPU's variables.  If the variables need to be rewritten, purge the
cache on the master CPU side.  In addition, do not execute functions that
issue functions to the slave CPU (such as those related to sprite control).

There are other interesting stuff in there so I put the text file in attachment if you want to check it out .

23

Share your code / Dual SH2 usage example

« on: April 09, 2017, 04:07:09 pm »

Hi dear friends!
After much digging around I figured out how to use the 2 SH2 CPUs, its rather simple actually but a light read on fork-join model is recommended to help grasp the concept.
Also, the Sega Saturn ram bus system does not have a bus snoop function so accessing shared stuff on the ram with both CPUs should be done carefully, either by doing a cache-through read (avoiding the CPU cache) or invalidating the whole CPU cache so you have fresh un-cached data available.
The source code for this "marvel" is in attachment, have fun and feel free to shoot any questions you have!

Note: Jo, I used 2 SGL function you might want to wrap around on your library:
- slSlaveFunc(void * pointer_to_function, void* pointer_to_function_parameter):
You can pass a single parameter to the function you are using but it will only work for the first so you can't use functions with more than one parameter, a work around for this is creating a struct and sending a pointer to the struct .
- slCashPurge():
This clears the Cache, I find it really funny how they mistook cash(Money) with Cache, probably Japanese translation errors?

24

General Jo Engine Help / Re: jo_sin_mult/jo_cos_mult return smaller/bigger value

« on: November 07, 2016, 03:54:08 pm »

Hi,
I know I promised a tutorial about first person movement but I have been busy  .
The last code I posted missed the full 3d movement and was not really well structured, sorry about that  .
I will try to make a tutorial this week with a full 3d movement flight camera.

25

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 19, 2016, 12:34:27 am »

That will be great 
I will do my best to help in what i can

26

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 18, 2016, 11:50:12 am »

I think i found the problem with the display polygon count.
I'm drawing 42 polygons, and it is showing 66.
If i do a conversion from decimal to hexadecimal of 66 the result is 42, which is the number i actually drew.
I think the value was already in decimal and suffered an unnecessary conversion.

27

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 18, 2016, 10:47:13 am »

Hi dear friend,
I think these SGL functions would be helpful:
-slZdispLevel: For changing the Front Boundary Surface (draw distance close to the camera).
-slWindow: Mainly the part that changes de Rear Boundary Surface (draw distance limit).
-slPrespective(): For correcting the perspective distortion on non standard resolutions, compensate for widescreen TVs or for artistic effect.
I know you are working on the high resolution mode, later on, an option to configure the resolution within the application would be nice  .

I will try to make a tutorial soon on what I found on making correct use of the space available for drawing the 3d environment, I tried to explain a little in the last post but its hard to explain it correctly without a diagram or visual aid of some sort.
I will also try to make a little video showing the ghost polygon count issue.

I did what you said about project and it worked, thank you once again  .

28

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 15, 2016, 04:56:15 pm »

Hi friend!
Thank you very much!
I also love Exhumed, its one of my favorite FPS games ever, Lobotomy Software made an excellent job on their Saturn games  .

Oh yes, I tested the "slZdspLevel()" SGL function because the polygons close to the camera were being clipped and was not understanding why.
It turns out I need to plan carefully where I draw them and their size/scale, if I draw the polygons too big they get clipped because I'm using to much space on the matrix.
For instance, with the default configurations, my observations led me to conclude that the drawing range is between around 400 to 7500 distance points from the camera.
For example if I draw a floor with square tiles with a width size of 1000 points I can only draw a distance of around 6 visible tiles, the closest tile would get distorted or disappear and the farthest visible one would have to be drawn within the 7500 points or it would also disappear.
The slZdspLevel() allowed me to still see the polygons closest to the camera but I eventually figured out this was not the solution although it might be helpful in some cases.
Also if I draw the polygons too small I would have trouble using the sine and cosine functions to move because there is just not enough detail to calculate the new camera positions correctly. For example I would rotate the matrix 60 degrees but if I wanted to move just 1 or 2 points I wouldn't actually go in that direction , I would need to move 20 or 30 points to get enough precision but then it would appear to be moving too fast because everything was "small" in comparison.
I also noticed the jo_3d_get_polygon_count() function is returning more polygons than I'm actually drawing on screen which is weird because you are getting that information from a SGL global variable right? The jo_3d_get_displayed_polygon_count() is also returning a number of polygons in some places even if they are not being displayed on screen, its like there are ghost polygons somewhere?
Maybe I am doing something wrong on my draw functions?

This post is getting really huge  maybe i should put all this information in another section?

I downloaded the latest update and tried to compile but Netbeans complains its necessary to "Resolve Missing Native Build Tools".
Maybe we need to manually setup these options on our host machines?

29

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 14, 2016, 10:29:45 pm »

Well I found a not so elegant way around it  .
What I did was to copy all files to the same directory, although they are all in the same place I can now ctrl + left mouse click to jump to the definitions, it also doesn't show warnings all over the place.
I added an attachement of the Netbeans 8.1 Project I used to test it, I think there is a way to have it more organized instead of having the files all jumbled up together .

By the way I'm trying to make a First Person Shooter in the style of Exhumed, I'm using the "demo - 3D" as a starting point to learn the basics, so far I figured out how to make basic the first person movement, I have it in this attachment if anyone wants to check it out.

30

General Jo Engine Help / Re: Help setting up a project on CodeBlocks

« on: October 14, 2016, 09:25:11 pm »

That would be great Thank you!
What I tried to do before was to add the JO-Engine header files to the Include Directories and Include Headers under the Project Properties - Build - C Compiler options but it didn't work. Maybe it will only work if I'm actually using a library file on the Linker options. I couldn't figure out how to make the compiler bundled with Jo-Engine work on netbeans either.