Yeah, waiting for a first public release, great job ! 
I just uploaded it to the archives. I will put the download link in the first post once I've seen it approved.
I've changed the font to the one in the original (which is the latest update thus far):
I've changed the font to the one in the original (which is the latest update thus far):
ProgrammerNerd wrote:
I can't wait for it to get accepted. Does the cookie scale?
Yes it does.
When you press the button it gets smaller so it looks like you're actually clicking it (which I think is neat).
I was going to make it so it got the seconds that had passed and multiplied it by the CpS at the startup (so it gave the affect of running in the background without actually running in the background), but the RTC resets to zero at midnight, so it subtracts instead of adding the next day if it's less than 24 hours passed the time it last saved.
Maybe if I can figure out how to check if it's the next day. 
The RTC stores time as well as date. The only thing that "resets" is the RTC_GetTicks function (in the same sense that time "resets" at midnight every day).
You only need to store a timestamp of when the add-in was exited and then compare with the timestamp of when the add-in is entered again, to know how many seconds have passed. This is more or less how chronometers in Utilities work.
Ah, and BTW, using the RTC would allow users to cheat very easily
You only need to store a timestamp of when the add-in was exited and then compare with the timestamp of when the add-in is entered again, to know how many seconds have passed. This is more or less how chronometers in Utilities work.
Ah, and BTW, using the RTC would allow users to cheat very easily
gbl08ma wrote:
The RTC stores time as well as date. The only thing that "resets" is the RTC_GetTicks function (in the same sense that time "resets" at midnight every day).
You only need to store a timestamp of when the add-in was exited and then compare with the timestamp of when the add-in is entered again, to know how many seconds have passed. This is more or less how chronometers in Utilities work.
Ah, and BTW, using the RTC would allow users to cheat very easily
You only need to store a timestamp of when the add-in was exited and then compare with the timestamp of when the add-in is entered again, to know how many seconds have passed. This is more or less how chronometers in Utilities work.
Ah, and BTW, using the RTC would allow users to cheat very easily
Yes, but changing the save file is pretty easy too.
How do I get the date from the RTC? It doesn't seem like any of the functions in rtc.h would help me with that.
There's a syscall...
...or you could take a look at the functions at https://github.com/gbl08ma/utilities/blob/master/src/timeProvider.cpp
Simon wrote:
syscall 0x02C0 : void RTC_GetTime( unsigned int*hour, unsigned int*minute, unsigned int*second, unsigned int*millisecond );
Reads the consistent time into hour, minute, second and millisecond, resp.. The function repeats automatically when a carry occurs. milliseconds is only as exact as the 1/128 second base-tick allows.
Reads the consistent time into hour, minute, second and millisecond, resp.. The function repeats automatically when a carry occurs. milliseconds is only as exact as the 1/128 second base-tick allows.
...or you could take a look at the functions at https://github.com/gbl08ma/utilities/blob/master/src/timeProvider.cpp
gbl08ma wrote:
There's a syscall...
...or you could take a look at the functions at https://github.com/gbl08ma/utilities/blob/master/src/timeProvider.cpp
Simon wrote:
syscall 0x02C0 : void RTC_GetTime( unsigned int*hour, unsigned int*minute, unsigned int*second, unsigned int*millisecond );
Reads the consistent time into hour, minute, second and millisecond, resp.. The function repeats automatically when a carry occurs. milliseconds is only as exact as the 1/128 second base-tick allows.
Reads the consistent time into hour, minute, second and millisecond, resp.. The function repeats automatically when a carry occurs. milliseconds is only as exact as the 1/128 second base-tick allows.
...or you could take a look at the functions at https://github.com/gbl08ma/utilities/blob/master/src/timeProvider.cpp
I'm not sure how to use that routine to get the date. I might be able to use your utilities code to help (if I can figure it out).
True, that routine doesn't give the date. There's another syscall that returns the time and date in BCD format. But it is probably easier to use the code in timeProvider.cpp. You can try adding timeProvider.cpp and timeProvider.hpp to your project, you'll need to modify them to remove some Utilities dependencies. The important functions start on line 117 ( https://github.com/gbl08ma/utilities/blob/master/src/timeProvider.cpp#L117 )
Well I tested your program and it works just fine although exiting was an "interesting" experience. The screen just went mostly white. Pressing the menu button again took me to the menu.
Yeah, I don't know why it does that. Here is the code I'm using for main:
Code:
I don't thing the SaveGame function should affect whether or not it actually goes back to the menu the first time.
Here's the current SaveGame function:
Code:
Let me know if you see anything that might cause this.
Right now I'm working on Golden Cookies. Until the CopySpriteMaskedAlpha routine works, they won't fade in/out. The way they work in this game is that you have to press the F button underneath it to click it.
Code:
int main()
{
Bdisp_EnableColor(1);
BuildingsReset();
srandom(RTC_GetTicks());
goldTime = GetNumSec() + 10;//random() % 600 + 300);
LoadGame();
while(1)
{
int key = PRGM_GetKey();
if(key == KEY_PRGM_MENU){
SaveGame();
GetKey(&key);
}
keyupdate();
drawBack();
drawStore();
cookiePush();
drawCookieData();
if(msgDisplay){
displayMsg(msg);
if(GetNumSec() == msgTime)
msgDisplay = 0;
}
goldenCookie();
if(GetNumSec() == frenzyTimeCpS)
frenzyCpS = 0;
if(GetNumSec() == frenzyTimeClick)
frenzyClick = 0;
addCpS();
Bdisp_PutDisp_DD();
Bdisp_AllClr_VRAM();
}
return 0;
}
I don't thing the SaveGame function should affect whether or not it actually goes back to the menu the first time.
Here's the current SaveGame function:
Code:
void SaveGame(){
char infoBuf[335];
int i, j, time;
unsigned short pFile[sizeof(PATH)*2];
Bfile_StrToName_ncpy(pFile, (unsigned char*)PATH, sizeof(PATH));
int hFile;
hFile = Bfile_OpenFile_OS(pFile, 3, 0);
if(hFile < 0){
int size = 335;
Bfile_CreateEntry_OS(pFile, 1, &size);
hFile = Bfile_OpenFile_OS(pFile, 3, 0);
}
itoa(cookies, CookieBuf);
for(i = 0; i < 15 - strlen(CookieBuf); i++){
if(i == 0)
strcpy(infoBuf, " ");
else
strcat(infoBuf, " ");
}
strcat(infoBuf, CookieBuf);
strcat(infoBuf, ";");
itoa((int)floor2(CpS), CpSBuf1);
strcpy(CpSBuf, CpSBuf1);
if((CpS - floor2(CpS)) * 10 > 0){
strcat(CpSBuf, ".");
itoa((int)((CpS - floor2(CpS)) * 10), CpSBuf1);
strcat(CpSBuf, CpSBuf1);
}
strcat(infoBuf, CpSBuf);
for(i = 0; i < 15 - strlen(CpSBuf); i++)
strcat(infoBuf, " ");
strcat(infoBuf, ";");
for(i = 0; i < 9; i++){
itoa(Buildings[i].Owned, OwnedBuf);
for(j = 0; j < 15 - strlen(OwnedBuf); j++)
strcat(infoBuf, " ");
strcat(infoBuf, OwnedBuf);
strcat(infoBuf, ";");
itoa((int)Buildings[i].price, priceBuf);
for(j = 0; j < 15 - strlen(priceBuf); j++)
strcat(infoBuf, " ");
strcat(infoBuf, priceBuf);
strcat(infoBuf, ";");
}
time = GetNumSec();
itoa(time, RTCBuf);
for(i = 0; i < 15 - strlen(RTCBuf); i++)
strcat(infoBuf, " ");
strcat(infoBuf, RTCBuf);
Bfile_WriteFile_OS(hFile, infoBuf, sizeof(infoBuf));
Bfile_CloseFile_OS(hFile);
}Let me know if you see anything that might cause this.
Right now I'm working on Golden Cookies. Until the CopySpriteMaskedAlpha routine works, they won't fade in/out. The way they work in this game is that you have to press the F button underneath it to click it.
*BUMP*
Got golden cookies working (I had to fix my own alpha sprite routine).
(probably not actual speed. The values are messed up because of the screen receiver; not sure why)
Also the file size is smaller now because I changed the font images from 16-bit to 1-bit using SourceCoder. I'll upload to the archives soon.
Got golden cookies working (I had to fix my own alpha sprite routine).
(probably not actual speed. The values are messed up because of the screen receiver; not sure why)
Also the file size is smaller now because I changed the font images from 16-bit to 1-bit using SourceCoder. I'll upload to the archives soon.
I'm glad that SourceCoder was able to help. Nice improvements; this seems like a relatively true port of the original game to the screen limitations of the Prizm. Because I haven't tested it out, I'm not sure if you can scroll past Factory to the other production units; can you?
KermMartian wrote:
I'm glad that SourceCoder was able to help. Nice improvements; this seems like a relatively true port of the original game to the screen limitations of the Prizm. Because I haven't tested it out, I'm not sure if you can scroll past Factory to the other production units; can you?
Thanks! And yes, you can.
It only goes up to Time Machines, though because the prices for the Antimatter Condensers and the Prisms are too large and display weird characters.
Also, when a golden cookie is on the screen, manual clicking and buying things is slower (I guess because my alpha sprite routine is slow). Maybe eventually I'll fix it by using a better routine (or optimizing mine), but for now, it is what it is.
I think PRGM_GetKey() may cause an action to occur when you press menu. To exit my programs I also first check if the key if the menu key was pressed then I use GetKey to cause the actual exit. The difference is that instead of using PRGM_GetKey() I use this
Code:
function.
Why not just put the game on github or something similar or at-least post the alpha sprite function?
I am sure I will have things to say about your alpha sprite routine and probably other things that could improve your program.
Code:
int keyPressed(int basic_keycode){
const unsigned short* keyboard_register = (unsigned short*)0xA44B0000;
int row, col, word, bit;
row = basic_keycode%10;
col = basic_keycode/10-1;
word = row>>1;
bit = col + ((row&1)<<3);
return (0 != (keyboard_register[word] & 1<<bit));
}
function.
Why not just put the game on github or something similar or at-least post the alpha sprite function?
I am sure I will have things to say about your alpha sprite routine and probably other things that could improve your program.
ProgrammerNerd wrote:
...or at-least post the alpha sprite function?
I am sure I will have things to say about your alpha sprite routine...
A good place for that would of course be our Useful Prizm Routines thread:
I am sure I will have things to say about your alpha sprite routine...
http://www.cemetech.net/forum/viewtopic.php?t=6114
I can make my own if needed. I am interested in why his is slow.
It appears as though he posted a similar function there but he said he had a problem with the function but he has since answered his own question as you can see in the screenshot he posted. Maybe when fixing the purple issue he introduced some additional slowness.
It appears as though he posted a similar function there but he said he had a problem with the function but he has since answered his own question as you can see in the screenshot he posted. Maybe when fixing the purple issue he introduced some additional slowness.
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement