gbl08ma wrote:
I think you'd better wait for libfxcg standard file I/O functions are implemented, after that, you'll be able to use fopen() and friends as you would do in any other C program.
You mean like how the basics are already there? Should try it because I want people to test. 
Personally I find the BFILE functions to be better than the standard C IO functions... in places. The fact that you can specify where to start reading or writing to on each read/write call is much better. I don't like the fact that the ram and from use different functions...
I wouldn't wait for the new functions. All that the fopen and such will do is call the bfile functions, last time I looked.
Edit. I am only talking about waiting for file functions,which you mentioned. I see that the new libfxcg provided printf.
AHelper wrote:
I wouldn't wait for the new functions. All that the fopen and such will do is call the bfile functions, last time I looked.
That's true, but they do more than that, and I think it's easier to just always use the standard functions rather than mucking about with the unusual device-specific functions.
Handling the difference between BFILE_* and MCS_* is something I haven't considered yet. Perhaps adding another flag to fopen (in addition to rwab) indicating MCS is desired..
Still, having the standard file functions helps reusing code from other programs and makes porting code much easier. I can't seem to get Bfile functions to work well when, for example, I don't know the size of the file I'm going to read beforehand (GetFileSize only seems to work well for files less than 4KB).
I understand the reasoning for standardizing file io. One idea for the ram/from is to just have the path like "ram://test.g3m" and "rom://folder/file.next". Doing a flag method can work. Matching the order above, fopen("test.g3m", "rwi"); and fopen("folder/file.next", "rw");, i being for internal. I personally like the second idea since you will not have to worry about the platform by default, since the internal memory has certain restrictions.
Edit
You don't need to know the size of a file you are reading to open it, iirc. You can seek to the end and get the position to find the size if you are having problems.
AHelper wrote:
One idea for the ram/from is to just have the path like "ram://test.g3m" and "rom://folder/file.next". Doing a flag method can work. Matching the order above, fopen("test.g3m", "rwi"); and fopen("folder/file.next", "rw");, i being for internal. I personally like the second idea since you will not have to worry about the platform by default, since the internal memory has certain restrictions.
Eeew, I will not do URIs, especially since that would utterly break attempting to run the code on other platforms.
This stuff warrants further discussion, but let's take it to the libfxcg thread to keep this one on-topic.
AHelper wrote:
I personally like the second idea since you will not have to worry about the platform by default, since the internal memory has certain restrictions.
Yes. I was just listing possible ideas. And sure, to the libfxcg forum I go.
Well I decided to use the BFile syscalls directly for now, though it should not be difficult to make changes in the future. After consulting Wikipedia, fx_calculators_SuperH_based.chm, and the source code for MPoupe's Gravity Duck I was able to create, read, write to, and close a save file.
AHelper, you warned me about endianness. I am familiar with the concept already but is there anything that I specifically need to know about?
If you're one-shotting things to a file from memory, it's not an issue. That's easier than reading little bits anyway..
Code: struct player {
unsigned short hp;
int xc;
int yc;
unsigned score;
};
struct player me = {
.hp = 9001;
.xc = 0;
.yc = 20;
.score = 27;
};
// Save..
FILE *f = fopen('foo', 'w');
fwrite(&me, sizeof(me), 1, f);
fclose(f);
// Reading back later..
f = fopen('foo', 'r');
fread(&me, sizeof(me), 1, f);
fclose(p);
Tweak to taste with BFile_* as desired.
You only need to be concerned about endianness mismatches if data might be created or read on a different processor.
I added part of the indoors "region" for the woods and desert regions. Rooms look a bit sparse but if I need to I can add more decorations. I also got the basic framework for shops done. I can start seriously thinking about a real gameplay demo after I flesh out the shop interface, do some more graphical work, and add just enough code and imagery for one battle.
Sounds good. Do you have most of the gameplay mechanics already sketched out in your head or on paper, or are you more letting the specifics evolve as you go?
The best part of this project is that I have notes, code, and experience from the original Prizm-Basic version of this game. The only aspects that I have to create from scratch are the parts that don't exist in that game. Everything else is documented to some degree in notebooks, a spreadsheet, sheets of graph paper, and the programs themselves. The only real challenge so far has been taking things that worked in Basic and making them work a bit differently with C. Other than that, I had a surprising amount of planning done before I even started this project!
More progress!
1) The shop system is set up now, you can now buy things and monitor your money and inventory from one menu. The shopkeepers are friendly and happily invite you to return someday of course, you will have very little say in the matter because you need supplies after all)
2) I implemented text scrolling for dialog. Eventually, you will be able to adjust the scrolling speed in the options menu.
3) I added the Game Stats menu. This menu tells you things such as how many steps you have walked and how much money you have spent. I will add more interesting things to track later.
I'm doing some spriting now. Everything I do is going to be based on the sprite that Spenceboy98 gave me. Astonishingly enough, this is the part of the project that I am the least certain of quality-wise. When the time comes, I hope you all can give me advice and tips on how to make the sprites better.
Yay! I hope you get a demo out soon.
m1ac4 wrote:
More progress!
1) The shop system is set up now, you can now buy things and monitor your money and inventory from one menu. The shopkeepers are friendly and happily invite you to return someday of course, you will have very little say in the matter because you need supplies after all)
This seems very much like a command economy :P
Tari wrote:
Code: struct player {
unsigned short hp;
int xc;
int yc;
unsigned score;
};
struct player me = {
.hp = 9001;
.xc = 0;
.yc = 20;
.score = 27;
};
// Save..
FILE *f = fopen('foo', 'w');
fwrite(&me, sizeof(me), 1, f);
fclose(f);
// Reading back later..
f = fopen('foo', 'r');
fread(&me, sizeof(me), 1, f);
fclose(p);
I think using a typedef for the structure would be easier.
Code: typedef struct {
unsigned short hp;
int xc;
int yc;
unsigned score;
} player;
player me = (player){9001,0,20,27};
// Save..
FILE *f = fopen("foo", "w"); //or "wb"?
fwrite(&me, sizeof(me), 1, f);
fclose(f);
// Reading back later..
f = fopen("foo", "r");
fread(&me, sizeof(me), 1, f);
fclose(f);
seana11 wrote:
This seems very much like a command economy
Sadly, it pretty much is a command economy. The shopkeepers get their supplies from some place far away and the shipments come through the port that is controlled by one of the bosses. As such, the markets aren't free at all. In fact, one could get a better feel for the situation of the village by taking a look at one particular building...
Is that syntax "(struct) {data}" works? Oo
I've never saw something like this!
It might work, but it's weird. If it works, it's an unnecessary cast that could end up hiding subtle bugs. Better to just do a block assignment, and I think it's much better to use new-style explicit member assignment so you don't get screwed up if the struct field ordering ever changes:
Code: player me = {
.hp = 9001;
.xc = 0;
.yc = 20;
.score = 27;
};
I have a functional battle system now. The only thing that is missing at the moment is that you can always flee from battles (that will be determined by probability later). With that, I have all the pieces necessary to work on the first part of the storyline! All that is missing are some acceptable main menu icons.
