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 - z80man
1
« on: December 23, 2011, 05:05:01 pm »
Could I get some comments on that routine. Always a good practice cause it can often be difficult for some people to understand others code. I'm out of town right now but I'll write something up when I get back tomorrow
2
« on: December 22, 2011, 01:16:02 am »
The size of float based routines is really quite negligible and they don't use any extra ram because the entire executable is stored in flash. You could use a fixed point float in this situation but I would advise against them in this situation as the best way to write them out would be to use pre-defined macros such as TWO_POINT_FIVE which would be 0x00028000 in a 32 bit fixed point notation. The other alternative here is to specify when calling the function what size you would like to scale it to instead of providing a scale factor. Perhaps in this situation 2 different functions ought to be developed. One for rather straightforward scales that can be easily implemented such as x.5, x2, x4 and so on. This would be called as 2 raised to the x power. For example passing 0 as the scale will result in a sprite with no change in size while 1 will be x2, 2 as x4, 3 as x8, and so on. That would also mean that -1 would be .5, -2 as .25 and so on. The second routine would require much more overhead and be called with either a float factor or specify the new image size. If this sounds good I can start work on the first routine and have that out in not too long.
Bump-bi-di-bump the topic for asking someone to realize zoo-msacled sprite drawing function. That could be very useful to some animations..
I think always that 2^factors would be easier and faster to use...
moderator edit: fixed
For shrinking sprites factors of 2 would be much faster while for enlarging there wouldn't be a difference. What could be done is that the routine checks if a factor of 2 is used and then resizes using the proper routine. It isn't too hard to check whether an integer is a factor of 2 or not especially if you limit the the scale size to something like x16
3
« on: December 14, 2011, 12:37:26 am »
If recompiled older add-ins should be able to work. There's nothing wrong with directly accessing the hardware as long as you do it in a safe and efficient way. My preferred method is to use a set of standardized libraries that can updated when hardware changes without having to modify someone's legacy code. For example a set_cpu_frequency(int) function could be designed to be both hardware compatible with all current casio calcs and be flexible enough to be expanded for future designs. This is also why I'm such a strong advocate for open-source projects as old apps that are no longer maintained by their original authors can no longer work if they were closed source. This is especially distressing if only a few minor modifications were required to upgrade to the newer gII. To prevent this in the future I've been working on standardizing methods for the Prizm as it will be necessary if casio changes the hardware. In fact I'm going to try and extend these hardware libraries to all casio calcs that way standardized hardware functions can be used for nearly half a dozen calcs. Do note that the professional software industry deals with these issues to a far more difficult level than we do. As an example look at the x86 architecture. The number of modifications and additions it has gone through is far more than the super h. And yet something like windows has to directly access the hardware on the tens of thousands of different pc's out there and is expected to work right out of the box.
4
« on: December 10, 2011, 02:39:05 am »
Unless you could call a C lib from a basic program then no. Such lib would need someway to individually identify the calculator it runs on such as for example checking a unique hardware id
5
« on: December 05, 2011, 02:44:08 am »
full color doom anyone?
6
« on: November 30, 2011, 03:31:50 am »
I thought prizm was SH-4A 
for the most part yes but it's actually a customized chip designed exclusively for Casio. Because Khavi will most likely interface with the core peripherals heavily it is important to note the differences.
7
« on: November 29, 2011, 01:44:01 am »
Where would you host it? I could host it free, if you want.
Wow! That'd be great if you could and if activity gets high on that site I'll help contribute to the cost of hosting. Now's not the best time as I'm very low on any free time but once I get off from school around mid December I'll contact you about seeing what we can do to get this going.
8
« on: November 28, 2011, 02:23:04 am »
Not much optimization I can see there other than changing the flags in the makefile. The only thing I might do is include some type casts because your arguments are unsigned chars which don't have the necessary width for your bit shifts. My own personal preference is to use 24 bit color and then convert it to 16 bits using a simple routine because it's much easier to write out in code but your method does have a speed advantage.
9
« on: November 26, 2011, 01:57:38 am »
Linux dev is actually quite simple to do as long as you have wine running. What I''ve done is replace the .bat scripts with compatible bash .sh scripts that do the exact same thing. That way I can still use make.exe and the makefile to compile and link my code into apps
10
« on: November 16, 2011, 03:32:36 am »
Yeah I like that idea because I had no intention to contain a forum other than maybe comments on news articles and app reviews.
btw very off topic but since when have you had leet ratings?
11
« on: November 16, 2011, 03:18:02 am »
Yeah I wonder if 2072 would be willing to expand for the Prizm. Also the current system is quite weird. It might be good to have something like ticalc.org, although it would be hard to get the old authors to add their files to the archives.
For authors that we can't get to upload to a new site there's always the possibility of providing direct links so that at least some resource is provided to download those apps. Everything else would be hosted directly on the archive. For the domain I was considering some ideas such as: casiozone.org casioalliance.org casiohub.org what do you guys think?
12
« on: November 15, 2011, 11:18:46 pm »
Considering both calcs have the same hardware it should be possible to do so just like you can turn a cg10 into a cg20 once we write the needed custom flash routines. Sounds like this will have to wait till the release of ndless 3
13
« on: November 15, 2011, 11:14:25 pm »
I agree that there should be some sort of center for the Casio archives, though I don't exactly see what's wrong with using an existing site.
Imho casiocalc sounds pretty good, tho I'll say casiokingdom's collection seems pretty impressive as well, also having the tutorials etc.
Both sites due to have good archive collections but they are quite limited and due not have any section dedicated to newer Prizm calcs. What I'm really looking for is a distribution system as well laid out as ticalc. One that is frequently updated with news and supports a large collection of programs and apps.
14
« on: November 15, 2011, 08:39:56 pm »
that would be alot of uploading...
true, but i wouldn't mind making this my personal project. I wonder how much ticalc.org pays a month for their hosting fees.
15
« on: November 15, 2011, 08:34:35 pm »
I was thinking of just a neutral database that would provide a single source for all Casio programs and apps. Problem with any current distribution system is that they are often hard to find and intimidating for new authors. Part of the fun of ticalc.org is the wide variety of quadratic solvers available. This is an activity I wouldn't want to suppress as we all got to start from somewhere.
|
|
|
Show Posts