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 - Danny

Pages: [1] 2 3
General Jo Engine Help / Re: A few questions about PCM functionality
« on: October 24, 2017, 10:03:15 am »
Has anyone used midi samples? They are quite small.
The Saturn has a great sound chip and midi should sound excellent!

Nope, the size of a pointer depends of the architecture. (32 bits => 4 bytes, 64 bits => 8 bytes, etc). It's just not portable.
Yes you are correct, I did not explain myself correctly, what I meant is that with void* you don't know the size of what you are pointing to so when you do pointer arithmetic it might not work correctly.
Like you said  the void* size depends on the CPU architecture, all the pointers in an application have the same size and that is why you can simply cast them from one pointer type to another, whatever the data the pointer is pointing to it just contains an address.
You can even have pointers that point to another pointers xD:
Code: [Select]
//have an int
int int_val = 1;
//save its pointer
int* int_pointer = &int_val;
//save the pointer to that pointer
int** pointer_to_int_pointer =&int_pointer ;
//now increase the original int with the pointer to pointer 8D
//int_val will now be 2

Hi friend!
C is a strongly typed language so it enforces correct use of types, but if you know what you are doing you can cast a pointer to something else.
You can cast the return pointer to the type you are using like int* or your_type* or a void* (which matches everything) and the warning will go away.
For example:
Code: [Select]
jo_file file;
char * temp_pointer;
super_duper_type * awesome_thing;

jo_fs_open(&file, "FILE.TXT");
jo_fs_seek_forward(&file, 4096); /* I assume that 4096 is the size of the part to skip in the file and to preserve in the buffer */
jo_fs_read_next_bytes(&file, temp_pointer + 4096, 42);

awesome_thing = (super_duper_type*) temp_pointer;
// or like this: awesome_thing = (void*) temp_pointer;

I think Johannes specified the temp pointer as char because when you use pointer arithmetic like temp_pointer+2 what you really are saying is temp_pointer+(2*sizeof(char));
If you do pointer arithmetic on a int* like int_ptr+2 what you are really saying is int_ptr+(sizeof(int))
If I remember correctly if you try to do pointer arithmetic on a void* it wont work correctly because void has no size, since it has no size the compiler does not know how much to add.

Share your code / Object Oriented C Programming Example
« on: October 15, 2017, 05:00:28 am »
Hi people!
I love programming with C but there are some concepts of object oriented programming that are very useful and are not natively supported like they are in C++.
This does not mean that they are not possible to apply in C!
I have made a small example that shows how to implement objects and polymorphism.
This example shows that it is possible to have different objects in an array while being able to use the same functionality on all of them.
I have just finished making this so it has no comments yet (sorry), but I will try to update it in the next few days.
I hope this is helpful for someone  :P

- Commenting code (there are some new comments but nothing really helpful).
- Build an automated tool to generate a skeleton source code

EDIT 1: Version 0.2
- Changed the object header to static, now all objects of the same type share the same header which saves memory.
- Added some defines to the object header to further simplify things.

EDIT 2: Version 0.3:
-Minor API changes to make it easier to understand.

About you / Re: Hello!
« on: August 01, 2017, 10:48:30 pm »
Hello and welcome!
You got some nice ideas, it already seems like something that could make a nice shooter =P
Keep it up!  ;D

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 10:43:20 pm »
Yeah, you are right, sorry man, I got distracted by the weird forward movement which had happened to me before so I over-focused on that.
I haven't taken a good look at your code yet  :-\, I will however be checking it during the next days to try to find a solution  :), it might be something simple we are missing.

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 03:26:07 pm »
The first time I used the JO Engine to make the First Person movement I had a similar issue, I pointed in a certain direction and I wouldn't go exactly in that direction. That was because of loss of precision, my workaround for that was just increasing the amount of space I was traveling forward so that the precision loss wasn't so problematic.
The problem is that if you have smaller 3D objects on your world when you are moving you will be going too fast.
Later when I re-used some of the SGL example code to make the VDP2 demo I just used the SGL functions, in that case I did not have the same issue. Maybe that was because I was using the SGL functions directly instead of the JO Engine functions for handling sinus and cosinus.
My guess is that you are having trouble in a part like this one:

Code: [Select]
position_increment[X] -= movement_speed * slSin(angle[Z]) / 10;
position_increment[Y] -= movement_speed * slCos(angle[Z]) / 10;

position[X] = position_increment[X];
position[Y] = position_increment[Y];
position[Z] = toFIXED(-35.0);

I can try to take at look at this later, in the meanwhile could you try with the slSin() and slCos() to check if it makes any difference?
I also used the SGL "ANGLE" data type and used the corresponding function to convert from degrees to it like in this example:
Code: [Select]
ANGLE testAngle = DEGtoANG(90.0);

I noticed that there is something in the SGL that might cause some confusion:
There is a macro that simplifies coordinate handling in a way of just declaring an array of 3 positions differently.
Let me just elaborate a simple example:

Code: [Select]
int test[XYZ];   // this is basically the same thing as "int test[3];"

test[X] = 1; // same as test[0] = 1;
test[Y] = 2; // same as test[1] = 2;
test[Z] = 3; // same as test[2] = 3;

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 11:54:01 am »
In the early days logical shifts would be usually faster because the compilers were not very good at optimizing and the outcome would be more CPU cycles than needed, on more recent compilers that is no longer the case, the one we are using is relatively recent and I think will optimize correctly.
The problem with logical shifts its that it makes the code harder to read, at least the SGL demos were in my opinion messy and hard to understand at some points because of this.
In the end, if the outcome of the operation is the same, for instance the result of (10 << 1) and (10*2)  is the same (20), the compiler should compile to a binary left shift in either case, the difference is that its easier to understand on the second example. Now if you really want to do a binary shift and you really know what the binary shift is doing (for example, you really want some binary digits truncated) you should comment that line unlike those guys at Sega did. The code will be cleaner for someone else that reads it and even for yourself if you haven't picked it up in a long time.
I hope this helps  :P.

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 30, 2017, 01:37:01 am »
Humm, it seems you are using the logical shift operators (, they might not be doing what you need/want, have you tried to change the code to use the "+=" and "-=" assignment operators instead?

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 28, 2017, 05:58:28 pm »
You have been making a really wonderful job, your effort and dedication are inspiring!
I really like your videos, they show your progress from scratch and the evolution you have been having since the beginning.
It makes me really glad to see all the little bits of stuff I have been making put to good use ;D which makes me want to help out even more!

Share your code / Re: Collision BB generator (WIP) + FPS demo
« on: July 28, 2017, 05:17:31 pm »
I'm sharing a modified version I made of the "Advanced 3D" that loads the mesh from ROM to RAM using direct memory access instead of a static allocation.
This requires a little bit of knowledge of pointer arithmetic but is worth the effort because it makes loading different meshes easier. The same approach can be used to load other stuff so I guess it's also a good starting point to learn.
I made this to help our friend XL2 with his game and he will be incorporating this on his great tool, but for now I thought it would be nice to share this with all of you in case you are curious :P.

Jo Engine Wish List / Re: 3D mesh drawing and collision detection?
« on: April 29, 2017, 02:08:44 am »
I'm working on the 3D Space Partitioning which is also related with this.
I have been reusing some SGL examples that come with the Saturn Orbit Development package, found here if you are curious, namely the "Racing" and the "Shooting" 3D examples. I tried to do some refactoring on these examples but it just seems impossible, there are a lot of "magic" numbers and I can't make sense of half of what is done there.
I mean, from the little bits I did understand of the map drawing part it looks like they are doing some sort of fustrum culling and have the map divided in areas for faster search but that's about it. The code was probably ported from assembly to C which is completely unreadable.
The collision detection used from what I understood was made like a second map with bounding areas (these areas might not match the 3d map 1:1) for example a race track only lets you move inside the track and not the rest of map,  the collision detection seemed to be done with collision sweep tests like these:
In the end I resorted to take the maps that have a lot of polygon data and try to re-use them for implementing my own 3d space partitioning.
It all falls down to how do we store the 3d map data, which is directly related to how is the 3d partitioning done, for example, BSPs and Octress can be used for collision detection.
Anyway, I wanted to help you so much but these things require a lot of study :o and I'm progressing at a crawling speed  :-\

Project announcement / Re: 3D Sonic demo
« on: April 29, 2017, 01:22:39 am »
My 3D implementation will be different from the SGL. Maybe the results will be better. I will release a beta in 2 weeks  :)
That is really good news, thank you very much Johannes!
I have been trying to implement a 3d space partitioning based on portals and maybe octrees (i'm still learning) and I'm using the PDATA and XPDATA SGL native structures for the polygons, will you still use them or make some new structures for this?

Project announcement / Re: 3D Sonic demo
« on: April 29, 2017, 01:14:35 am »
Yes, I have also read that part. The SGL manual is pretty useful. In fact I shrank my Sonic model to the minimum to also allow a good view while also preventing clipping. The Saturn is struggling really badly with huge polygons. It forces me to subdivise the whole map in several small polygons just to prevent the framerate from dropping. I have also added a projection window for far object clipping, which should help. I'll add several debug options for next time I burn a disk and try it on actual hardware. Do you know about a Jo Engine function to get the actual displayed framerate? Or should I just create one?
Sorry friend, I have been busy at work and havent had much time to check up the forum, I'm not sure but I don't think there is a function for that, however you can set up the processing time of each frame on conf.h by changing JO_FRAMERATE to a slower framerate, this way the vdp1 has more time to draw stuff(I think). I know this does not help you much but I remembered it might be helpful although the conf.h file says "DONT TOUCH THIS FILE" xD.
As for measuring the cpu time you could use the clock tiks like i did in the dual cpu usage example  ???.

Project announcement / Re: 3D Sonic demo
« on: April 25, 2017, 10:28:18 am »
It seems to me the problem is the polygon clipping when you get close because when you are far away everything seems to be shown fine  ???
You could try to use jo_3d_display_level() to adjust the near clipping but I'm not entirely sure if that will fix it, it might also be a problem somewhere else.
The jo_3d_display_level()  is an abstraction of the slZdspLevel, the parameters work like this:


example values for level:
1: Display from 1/2
2: Display from 1/4
3: Display from 1/8
I have an image file as attachment that helps explain this.

I did some tests with this and although this function is helpful the problem might not be related, because on your video some things that are close do not disappear while others do.

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