Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Suggestions for libraries (long term, I am aware some are extremely difficult)
Game library
Hooks library
System variable library
Physics library
Multiplayer library
KingInfinity wrote:
Suggestions for libraries (long term, I am aware some are extremely difficult)
Game library
Hooks library
System variable library
Physics library


You should make them yourself! That's the part of the beauty of C. The hooks library is something that might take a little assembly, as well as the system variable library, but the game/physics libraries are perfectly doable by anyone. It would be great to have them, so you should bring up the SDK and start programming!
pimathbrainiac wrote:
KingInfinity wrote:
Suggestions for libraries (long term, I am aware some are extremely difficult)
Game library
Hooks library
System variable library
Physics library


You should make them yourself! That's the part of the beauty of C. The hooks library is something that might take a little assembly, as well as the system variable library, but the game/physics libraries are perfectly doable by anyone. It would be great to have them, so you should bring up the SDK and start programming!

Yes; making statically linkable libraries in C is relatively simple. And since ZDS outputs the assembled C source; you can pretty much copy/paste functions into your own assembly library for use with LibLoad. Of course; this also gives you an opportunity to optimize the compilere's assembly as well, a much needed thing for library routines. I'm going to finish v2 of the graphics library first; and then add easy tilemapping support in v3 probably. I may take a break and make v2 of the fileio library, which will include easy access to TI variables and data.
Speaking of static linking, I assume that the toolchain can statically link libraries into C programs as well?
KermMartian wrote:
Speaking of static linking, I assume that the toolchain can statically link libraries into C programs as well?

Currently not the shared ones, as I don't see much point in that, as it would just lead to a lot of duplicated code and a lot less room for people to make their actual programs. But if it was a necessity for some people; I guess I could add that pretty easily.
What are the best practices when you're dividing your code between multiple files? Two .c's? I tried that with the demo0 included with the SDK, and with a separate .c file for the /* other functions */ functions, bad things happened with and without #include <ti84pce.h>. With it, linking had a lot of duplicates. Without it, _OS() is undefined. Any recommendations? Thanks!
AFAICT, the duplicate symbols in the linking aren't actually harmful, but this is an open issue.
elfprince13 wrote:
AFAICT, the duplicate symbols in the linking aren't actually harmful, but this is an open issue.
I'm not sure that's actually the case. The binary I get from this technique is 532 bytes (compared to 488 bytes for the entire code in one .c file), and it crashes instantly on launch. The binary from the entire code in one .c file runs to the end of the _GetKey, then crashes while (presumably) cleaning up.

Is that a known bug in the demo0 demo, by the way?
I don't know what the demo0 demo is, but I consistently get a huge pile of duplicate symbol errors when linking, and they haven't caused runtime problems.
What is the format for sprites? Is there a way to convert images (like sourcecoder)?
Spenceboy98 wrote:
What is the format for sprites? Is there a way to convert images (like sourcecoder)?


ConvPNG is your friend: https://www.cemetech.net/forum/viewtopic.php?t=12379
KermMartian wrote:
elfprince13 wrote:
AFAICT, the duplicate symbols in the linking aren't actually harmful, but this is an open issue.
I'm not sure that's actually the case. The binary I get from this technique is 532 bytes (compared to 488 bytes for the entire code in one .c file), and it crashes instantly on launch. The binary from the entire code in one .c file runs to the end of the _GetKey, then crashes while (presumably) cleaning up.

Is that a known bug in the demo0 demo, by the way?

Well, it wasn't a bug before I was silly Smile Thanks for cleaning and adding all the things. There's a simple demo 1 now too. (I would also recommend others download the updated zip, unless you aren't having any problems Razz)

Here it is: https://github.com/CE-Programming/toolchain/releases

EDIT: Also, this is a question regrading multiple inclusions of ti84pce.inc. The issue is that since the functions are xdefd within the actual ZDS C runtime library, there's no easy way to redefine them to point to the ones present in the calculator's bootcode without getting multiple warnings. Would it be best to just recompile the libraries to use pointers to the functions on the calculator? That's the main problem.
Thank you for tracking down the problem! From what you said on IRC, it sounded like a stack pointer was running amok? I've updated SourceCoder 3 to use this new release of the toolchain.
KermMartian wrote:
Thank you for tracking down the problem! From what you said on IRC, it sounded like a stack pointer was running amok? I've updated SourceCoder 3 to use this new release of the toolchain.

Haha, yeah, the stack pointer was being stored in safeRAM, which was then cleared on exit. I opted to store it in the data section, probably a safer place than the bss Razz Anywho, awesome, hopefully I can fix all the open issues soon too Smile
MateoConLechuga wrote:
EDIT: Also, this is a question regrading multiple inclusions of ti84pce.inc. The issue is that since the functions are xdefd within the actual ZDS C runtime library, there's no easy way to redefine them to point to the ones present in the calculator's bootcode without getting multiple warnings. Would it be best to just recompile the libraries to use pointers to the functions on the calculator? That's the main problem.


Oooh, yeah, that makes sense. I forgot there were bootcode implementations for parts of the runtime library. Are we pretty sure that the rest of it is *not* present, or is its state unknown?
Feature request (not sure if I'm supposed to post these here):

Code:
gc_DrawScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);
gc_DrawTransparentScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);
It's probably best to open an issue on the github page and tag it as an enhancement.
Spenceboy98 wrote:
Feature request (not sure if I'm supposed to post these here):

Code:
gc_DrawScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);
gc_DrawTransparentScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);


v2 of the graphics libraries is planned to have this and a whole lot more. Making these functions takes time though Smile
MateoConLechuga wrote:
Spenceboy98 wrote:
Feature request (not sure if I'm supposed to post these here):

Code:
gc_DrawScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);
gc_DrawTransparentScaledSprite(uint8_t *data, uint16_t x, uint8_t y, uint8_t w1, uint8_t h1, uint8_t w2, uint8_t h2);


v2 of the graphics libraries is planned to have this and a whole lot more. Making these functions takes time though Smile


Sounds great! Very Happy I look forward to it!
I've found a bug in both CEmu and my real calc.
I've this program:

Code:
#include <ti84pce.h>
#include <fileioc.h>
#include <graphc.h>

char appvarName[] = "EXPR";

void print(const char* string, uint8_t col, uint8_t row);

void main(void) {
   unsigned int file, size;
   unsigned char array[];
   
   ti_CloseAll();
   
   ti_OpenVar(appvarName, "w", Program);
   ti_CloseAll();
}

void print(const char* string, uint8_t xpos, uint8_t ypos)
{
   _OS( asm("LD HL,(IX+6)");
      asm("LD A,(IX+9)");
      asm("LD (curCol),A");
      asm("LD A,(IX+12)");
      asm("LD (curRow),A");
      asm("CALL _PutS");
   );
}

I transferred it, and the libraries too. The first time it run correctly. But if I then clear the homescreen, call Asm( and press [PRGM] it freezes somehow.

Maybe you fixed this in a later version?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 17
» All times are GMT - 5 Hours
 
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

 

Advertisement