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.
), but that can be removed or changed in 2 secs.(You can't copyright a font, only the data used to make a font. i.e. the display is ok, but distributing a .ttf file without permission is not)
//fast, lame and poorly named code
int read_data(char* buffer_pointer, int bytes_to_read)
{
int bytes_read=0;
while((bytes_to_read>0)&&(bytes_left_in_file>0))
{
if(bytes_in_sector==0) read_next_sector(§or_pointer,&bytes_in_sector);
int bytes_to_copy=min(bytes_in_sector,bytes_to_read);
memcpy(buffer_pointer,sector_pointer,bytes_to_copy);
buffer_pointer+=bytes_to_copy;
sector_pointer+=bytes_to_copy;
bytes_left_in_file-=bytes_to_copy;
bytes_to_read-=bytes_to_copy;
bytes_read+=bytes_to_copy;
bytes_in_sector-=bytes_to_copy;
}
return bytes_read;
}
This code assumes it's contained in some class and all the vars not explicitly declared are assumed to be instance variables initialized before calling.
Giga, of you have an issue with variable_naming, you could always write a wrapper class or something. I personally hate CamelHump variable names, but abided because Akari likes them.Oh don't worry I will help if I think I can... even if I don't like the naming conventions.
But I think you'll agree, that using SDL_xxx is a LOT easier than writing another output class for each platform.Sure, but I still don't really like it's naming convention.
Actually, we are going to need MOD-type player. I'll need to hunt down the SEQ data format. I only know the container format, but not what's in it. I know in the "raw" form of SEQ music sequences, they use VAG files for the music samples (Kind of like a soundfont) We have the original uncompiled MIDI files from the PC version so if we liberate the data out of the SEQ container, or whater it's in, we can most likely reverse the music pretty easily.Well SEQs are probably more MIDI-style than MOD, that if they didn't just use MIDI data directly, like lots of ps2 games do... in that case it wouldn't be too hard to do one. I wrote a midi disassembler once (converts a midi stream to instruction mnemonics), and from what I know from the psx sound hardware, I think it wouldn't be too hard to make a sequencer. So if there is the need, tell me.
An intresting way to do music is to take some code from an open source PSX emulator, or one of it's audio plugins to make it sound correct. The "Heart" of our sound system might just be an emulated PSX sound chip. How does that sound to everyone?Well as I said I worked on a spu2 plugin (ps2 sound processor), and it's just like the ps1 spu, but doubled, so I know the insides kinda well (and could provide some code if needed, and I have it). From that I would just say emulating the whole spu would be pointless, but if you jsut take the decoder, mixer and effects processing, then it's a nice idea.
Script at block 0, file 2, enemy 0, section 2:
0000h: 81 60 08 34
0004h: 60 00 <-- there is another 60 xx pair below so maybe this one is a single instruction too... (if 71 is "jump if flag", this could be comparing?)
0006h: 71 27 00 <-- 71 0x0027 == probably 71 is some "jump if (flag set?) to address 27h"
0009h: 93 "monster" b2 "Not a probrem" b3 ff <-- 93 looks like a "show dialog" opcode
0021h: 72 62 00 <-- another jump, with diff condition code?
0024h: 72 2c 00
0027h: 60 01 <-- I wonder...
0029h: 71 46 00
002ch: 93 "monster" b2 "I'm sorry" b3 ff
0040h: 72 62 00
0043h: 72 46 00 <-- given the next instruction is already at 46h, this looks like a "nop"...
0046h: 93 "monster" b2 "That's too bad" b3 ff
005fh: 72 62 00
0062h: 91 <-- I wonder too
0063h: 73 20 00 <-- this 0x0020 points "nicely" to the 11 10 ... at the 0084h line, so it could mean 73 is a "jump offset"
0066h: ff ff ff ff
006ah: 2b 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0084h: 11 10 20 01 10 20 60 01 30 90 73
008fh: 11 18 20 01 18 20 60 01 30 90 02 60 20 60 08 87 40 70 29 00 01 18 20 60 01 40 70 29 00 12 70 20 02 80 20 90 60 20 60 23 92 73