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

Pages: [1] 2 3 ... 9
I'm glad I can help, hopefully I did. Also, I've pushed a million edits to the post.

I downloaded the demo.

You've got a few problems in this code, mainly too many callbacks. Way too many. You should be program-controlling whether or not things run inside a "game_loop" function. You shouldn't need more than 1 callback for the game, and 1 for the video. The bad pointer is because you are working with too many callbacks, and removing some of them. I don't want to be too harsh, you definitely have something, and I wish you the best of skills.

Secondly, BACKGROUND.H is consuming too much memory. To be precise, it is consuming about 600KB of high memory. There simply is not enough memory for the video to play when you include the background like that. Even if Jo engine is passing it off to VDP2, since it is included in the program itself, it is not an area available to memory allocation by default.

You MUST use binary files for ALL models, sprites, textures, and background data. To do this you should look at XL2's model loading tools and demos.
If you don't do this, you will continue to face mysterious crashes from SBL/SGL functions that basically destroy everything whenever they are out of sectors to run with, since Jo engine is front-loaded into high memory.
/e: When you move to program-controlled binary file loading, you should be able to use LWRAM for your project, even if the CPK eats up all of high memory you might not need that.
And, in that circumstance, your massive VDP2 background can be overwritten in LWRAM since it doesn't need to be there anymore.

Lastly, Jo Engine is not designed to have videos be program-controlled, as we thought it could be. You MUST load the CPK ONLY ONCE. Jo designed it to be a part of the program that is run, and then ignored. If it is inside a system callback, you're going to have trouble. As far as I have been able to test, this is the only correct way to play a video:

Code: [Select]
    if (jo_video_open_file("SAMPLE.CPK")){

Your error code 101 is the following:
Code: [Select]
	CPK_ERR_OUT_OF_HANDLE		= 0x00000101,/* ハンドル売り切れ 			*/
Essentially that means when you have it as part of a system callback, too many CPK handles are created since it's running every frame.

I haven't fixed your problem, but hopefully I have armed you with enough information to proceed.

/e: a million edits

That's interesting. That address is in high memory (you only have 752 KB / 376 sectors to use there in total and the program takes some of that). It isn't stopping on a sector, so I can see why the address is bad; it isn't an even divisor of 2048. Memory must be managed in sectors (2048 bytes / 2 KB) or else crashes like this will happen.
I don't know if that will help you. I suspect that trying to run any game code alongside the CPK system is going to cause problems...
Perhaps use "jo_core_add_callback" in an IF statement inside main to add the callback for the game code if pad1 presses a key. (you would trigger this with a bool that is set true when you hit the key, so you don't have to press it constantly)

Throw up your working folder, I'd like to look.

General Jo Engine Help / Re: Why is this skipping?
« on: Today at 01:54:27 am »
Don't worry, I appreciate you reading though.
Buffers are more complicated than I would have expected. Which is good, I'm in it for the challenge

General Jo Engine Help / Re: Why is this skipping?
« on: July 15, 2018, 02:33:15 pm »
Yes, you can ignore this, I have other problems to solve but I am making progress.

General Jo Engine Help / Why is this skipping?
« on: July 15, 2018, 09:10:08 am »
If anyone bothers to look at this, that's cool.

If you are someone who is particularly short on time / has better things to do (like XL2), best to move on, because I have been fumbling around with an interruptible PCM playback system for more than a month now (and there are already better solutions, but I'm stubborn).
I thought I had it good, and I do have working concepts, but I've come to the conclusion that I need a buffer to give the Saturn time to switch files in the case I want to load something while the music is playing. Otherwise, the music has to halt. I have no experience with this kind of thing...

Code: [Select]
#define PCMRAM	(631734272)
#define LWRAM (2097152)
#define HIMEM (100679680)
//HIMEM has 376 sectors (752 KB)
#define HIEND (101449728)
//Each buffer is 8 sectors / 16 KB, a total of 32 sectors / 64 KB
#define PCMBUF1 (101433344)
#define PCMBUF2 (101416960)
#define PCMBUF3 (101400576)
#define PCMWORK (101384192)

#define M3072KHZ     (31118)

Code: [Select]

Sint8* music = "SCARE.AIFF";
    music_pcmfx.mode = JoSoundMono16Bit;
//This function is supposed to play a mono PCM sound effect constantly.
//Some HIMEM is consumed in the process (32 sectors / 64KB at the END OF HIMEM)
Sint32 fid_m = GFS_NameToId(music);
music_fs = GFS_Open(fid_m);
Sint32 msize;
Sint32 nsct_m;
Sint32 stat;
Sint32 rdsize;

Sint32 nsct_f;
Sint32 fsize;
//GFS Error Information
Sint32 a_stat;
//Get sectors
GFS_GetFileSize(music_fs, NULL, &nsct_m, NULL);
GFS_GetFileInfo(music_fs, NULL, NULL, &msize, NULL);
//This determines playback time?
music_pcmfx.data_length = (msize);
_pcm[(int)0].mode = (Uint8)music_pcmfx.mode;
_pcm[(int)0].pitch = M3072KHZ;
//How many frames are we reading?
if(rt_step < msize){
music_sectors = (msize + (rt_step - 1))/(rt_step);
jo_printf(0, 18, "(%i)", msize);

GFS_SetReadPara(music_fs, rt_step);
GFS_SetTransPara(music_fs, rt_sector);
//music_fs should be SCU type since it's going to high memory.
GFS_SetTmode(music_fs, GFS_TMODE_SCU);
//Seek music to the desired location
GFS_Seek(music_fs, play_ref, GFS_SEEK_SET);
//MUSIC loading follows
GFS_NwCdRead(music_fs, (20 * 2048));

//Let's make a pre-playback loop to read from the CD to fill a series of buffers using a work buffer.
for( ; buffers_filled < 3 ; ){
if(buffers_filled == 0){
rd_pcmbuf = PCMBUF1;
if(buffers_filled == 1){
rd_pcmbuf = PCMBUF2;
if(buffers_filled == 2){
rd_pcmbuf = PCMBUF3;
if(music_frames == 4){
slDMACopy(PCMWORK, rd_pcmbuf, (8 * 2048));
buffers_filled += 1;
music_frames = 0;
if(music_frames < 4){
GFS_NwFread(music_fs, rt_sector, PCMWORK  + (music_frames * rt_step), rt_step);
play_ref += 2;
// game_code();
if(music_frames < 4){
GFS_NwGetStat(music_fs, &stat, &rdsize);
jo_printf(0, 20, "(27)");
jo_printf(0, 7, "(%i)", music_frames);
jo_printf(7, 7, "(%i)", play_ref);
jo_printf(0, 10, "(%i)", stat);
jo_printf(0, 11, "(%i)", fetch_timer);
jo_printf(10, 11, "(fetched filesize)");
}while(stat != GFS_SVR_COMPLETED && rdsize < rt_step);
jo_printf(0, 22, "(%i)", buffers_filled);
//Let's then make a test loop to playback in sequence the three playback buffers that have been filled.
for( ; buffers_filled > 0 ; ){
// game_code();
jo_printf(0, 20, "(49)");
jo_printf(0, 11, "(%i)", fetch_timer);
jo_printf(0, 22, "(%i)", buffers_filled);


if(fetch_timer == 8){
buffers_filled -= 1;
fetch_timer = 0;
if(buffers_filled == 0){
curpcmbuf = PCMBUF3;
if(buffers_filled == 1){
curpcmbuf = PCMBUF2;
if(buffers_filled == 2){
curpcmbuf = PCMBUF1;
slSndFlush(); = curpcmbuf; //this line does not matter
music_pcmfx.current_playing_channel = 0;

slSoundRequest("bbbbwbb", SND_PCM_START, 0, 0, 631767039, (0), 0, 0, 0);

slPCMOn(&_pcm[(int)0],, music_pcmfx.data_length);
//buffers_filled = 0;

Actual transfer into PCMRAM to play is handled at Vblank with an interrupt:

Code: [Select]
void	my_vlank(void){
//A new music buffer system is needed.
//A filled-by-request buffer of 4x8 sectors, 32 sectors, 64 KB, at the end of high memory...
//A system managed .. how? The core issue is the file system slows down the entire Saturn, causing skipping.
//Tenets: GFS Seek has a variable completion time (but does not halt the system). GFS_Close does not complete immediately.
//Management of the buffer system must never close or re-open the music file, unless the buffer is completely full.
//Copy memory from work area buffer directly into the PCM stream buffer
slDMACopy(curpcmbuf, PCMRAM, (8 * 2048));

General Jo Engine Help / Re: Can't compile demo1 on Windows 10
« on: July 15, 2018, 09:05:54 am »
I think deevus is onto something. My first thought is check the makefile; if you can compile any other demo, copying over the makefile from that one into demo1 can change things...

Project announcement / Re: Sonic Z-Treme
« on: July 14, 2018, 09:27:45 am »
Do not get me started on the endless trial that is emulators...

General Jo Engine Help / Re: Text box for RPG
« on: July 13, 2018, 08:55:21 am »
Line 18 and 19:
Code: [Select]
	start_y -= 122;
stop_y -= 122;
//I added 10 because I am using a base of 352x240 instead of 320x240, concept will be the same

become instead:

Code: [Select]
	start_y -= 122 + (0.5 * given_y);
stop_y -= 122 + (0.5 * given_y);
//for 320x240, try starting at 112

Attached is a compiled sample.

General Jo Engine Help / Re: How to autoload game after video
« on: July 12, 2018, 08:50:29 pm »
At this point, you're going to have to look over the SBL GFS documentation (and the way Jo engine loads the file) so you can make your own function to load the CPK without a malloc. By doing that, when Jo engine loads something else, it won't try to append it to the end of the allocated area.
Relatively simple, you just need to identify the struct that jo engine wants the CPK in and read up on how GFS_Load works.

General Jo Engine Help / Re: How to autoload game after video
« on: July 10, 2018, 10:03:37 pm »
My guess looking at jo_free, whatever variable you are using to reference the data (like jo_get_video_sprite), you put that in jo_free.
Maybe the man himself will come and explain it for cinepaks.

General Jo Engine Help / Re: How to autoload game after video
« on: July 10, 2018, 04:55:23 am »
You should have a look at the jo_free command, since you're loading everything with Jo engine.
You should be able to use jo_free to free up the memory allocated by the video.
That said, I don't use jo engine loading features so I am not sure how it works.

General Jo Engine Help / Re: Request for real hardware tests
« on: July 07, 2018, 09:54:42 pm »
Well, you did help me, knowing that I should be putting sound stuff in high memory (if not sound memory).

Variable interpolation would be changing an animation so that each keyframe can have a different amount of frames interpolated between them.
It should just require some manipulation of the current interpolation code to skip forward a certain number of interpolated frames, or something like that, that's tomorrows job.
I should get my next stack of CD-Rs next week so there's no rush, I will have more things to test by then anyway.

General Jo Engine Help / Re: Request for real hardware tests
« on: July 07, 2018, 07:55:09 pm »
Okay, I'll get a cam out and record it real soon. It's entirely reasonable to use HIMEM instead of LWRAM as the buffer so next time I have some CD-R I will try that.
It's real simple. The model/polygons matrix just isn't getting transformed at all. No rotation. In time I'll see what using HIMEM does.

Here is (bad) video:

Here's an updated code set that uses HIMEM (actually an offset at the end of HIMEM as HIEND - (8 * 2048) ) as the sound buffer instead of LWRAM:
[Use this if you would like to see if the static suppression works on your console)

Mostly bugging you about the matrix issue since I don't have any suitable CD-Rs left and I have to wait a week for new ones to get here :)
Thank you for the help.
In the meantime I can move on to fixing up to get variable animation interpolation.

General Jo Engine Help / Re: Request for real hardware tests
« on: July 07, 2018, 11:08:01 am »
Hey guys,

I've got one last tentative request for some tests. I've used up my last pocket CD-R (dont worry I can get more).
This isn't urgent by any means, but I do have another case of hardware-emulator divergence, but this is in a way I think I already understand.

In the meantime, I have "fixed" (forged a workaround for) the static problem by injecting my own static (using slSoundRequest) and setting its volume to zero.
I've also set this little test up so it will load the model file, too.

The issue is, when it's playing the music, my matrix transforms are all screwed up! My guess is it won't do this because when the game code is stuck in the music playback loop, it doesn't have access to the slave CPU to perform the transformations. That, or DMA for the music is just blocking all access to VDP1. Which would suck. XL2 would know more about that.
Confusingly, this is another thing that only happens on real hardware. No emulators replicate it.

But, you don't have to test this one for me. You guys helped a lot the first time. Mostly I want to know if the static is gone. Then I shouldn't need more tests like this.
I wonder how many times XL2 has had to deal with emulator-hardware divergence? ^^

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