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
16
« on: November 15, 2011, 12:52:58 am »
One thing that the Casio community currently lacks and I believe is holding it back is an archive system similar to ticalc.org. Other Casio hosting sites, are often anti-gaming, nearly dead, or rarely frequented. Although the Omnimaga archives are great they aren't as open to the public as other systems are. What I was wondering was if it would be possible to host a site dedicated to maintaining archives of programs developed for Casio calcs. There are certainly many cost considerations as hosting a site isn't free and it would also need to be structured in a way so that it wouldn't compete with existing calculator based sites. Would anyone else support a similar venture?
17
« on: November 13, 2011, 07:52:47 pm »
When you see a Linux lover buy a Mac 
when i actually did because i was hired to make an iphone app and my mac emulator project wasn't working out... note: even though i'm obsessed with emulator's i never tried making a mac emulator note2: and yes i'm posting this from virtual box
18
« on: November 03, 2011, 01:25:07 am »
Why don't we have access to screen border?
Do you mean in BASIC because that's pretty common in any calc basic language but in C you have full access to the 216*384 screen.
19
« on: November 03, 2011, 01:21:10 am »
20
« on: November 02, 2011, 03:39:54 am »
Let's see how well the quick reply works.
Edit: pretty snappy
21
« on: November 01, 2011, 11:13:48 am »
Well, that's not really optimization at that point. That's a poor choice of speed optimization over the more sensible size optimization. (You seem to have ignored that programs can also be optimized for size.  )
that's what I meant there by size optimization. Many people forget the all important size optimization and focus on speed. It also should be noted that on the prizm a size optimization is often also a speed increase too because of the reduced chances of a cache miss
22
« on: November 01, 2011, 02:25:56 am »
Yes Oktoberfest has plenty of beer. Many people get what's called "das boot" (see example below) 
23
« on: November 01, 2011, 01:53:51 am »
Also, the second may not be true for programming utilities like interpreters and emulators. In such reasonably uncommon situations, extreme optimization is often entirely warranted (and lamented if not present).
Very true but those kind of projects are not very common. Unless a program is pushing the limits of the hardware extreme speed optimization is not necessary. In addition to emulators and interpreters games such as fps's could also fall into this category. One of the main reasons why I put that there is that I find it annoying in some programs when you see a function that is called at most once per second and is optimized to save 10 T states at the cost of 30 additional bytes. That there is just bad programming and all it does is increase the size.
24
« on: November 01, 2011, 01:46:58 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.
25
« on: October 30, 2011, 07:12:41 pm »
Here is a list of rules and suggestions that I believe those who develop for the Prizm should keep in mind for their apps. Many of these apply to all platforms whether it be other calculators or computers but a few are more targeted at the Prizm. - Treat the user's calculator with respect. Don't use any code that will put THEIR calculator at risk! Test your programs extensively and remove any holes that could potentially cause a major error. Even if you're not liable for damage, these types of incidents can tear apart communities.
- Applications need to be free. I shouldn't have to even say this one because it rare to happen on a calculator and no good distribution method currently exists. Do note that if you choose to follow this path, few if any people will buy your apps.
- I can't force you to do this, but open source really is a good idea. Source stealing is very rare these days and you really shouldn't care too much if someone borrows a routine. Yes, they should credit you but it's not like your losing any money by their doing so. These are free apps, by the way, so any sharing is only benefiting the common good and remember that our goal is not to please ourselves but to please our users.
- If you choose to follow an open-source approach, keep your code very clean and well commented. Explain what each function does and how the more complicated algorithms work. Additionally, you should provide documentation for the user on how to compile the application or, better yet, provide a shell script and makefile.
- Do everything you can to remove bugs. The best way to find bugs is to try to purposely break your programs to see how they respond to odd conditions. If a program asks a user to enter in how much money they would like to bet, enter a negative number and see what happens and if needed fix the resulting bug or glitch. Another good way to test for bugs is to release alpha and beta versions of your apps because others may find issues you never knew existed.
- Provide a line of communication for your users. Not everyone has an account on Omnimaga or Cemetech, so you need to provide an email, not only so you can provide the occasional help but also so users can report those all-important bugs.
- Your distribution file should include a readme. This should contain usage instructions, compilation directions, and how you can be contacted. Make it easy for the user to find what they're looking for and don't make it too long.
- Value user friendliness over extreme optimization. I'm not condemning optimization—in fact, every program should be extensively optimized—but what I'm warning against is overdoing it. You should always program in extensive exception handlers to prevent the user from breaking your apps. Graphical appearance should also be focused upon. Most users would prefer a sharp UI over an additional frame per second.
- If this is an ongoing project, updates should be regularly released and easily available. Even if an update only fixes a few minor bugs it is still worth it to release.
- Maintain a project topic on a calculator forum. It is recommended that the first post contain all of the most recent updates, screenshots, and information as it is easiest to find in that format. It is also a good idea to have a change log there or in your readme file as it provides a full development history.
- Remember to credit everyone who helped with development of your project. This includes programming, graphics, ideas, music, etc. This should be done in the readme, the project topic, and if possible within the application itself.
- Design your programs to have full forward compatibility and, unless it would hinder application development, full backward compatibility. Don't assume that Casio will never modify the Prizm in the future because chances are that we will see some major changes just like we've seen with every other calculator in history. How you do this is up to you, but one way to do this to make effective use of syscalls as they are pretty well written in stone; a well designed program or routine will also stand the test of time.
- Keep a common user interface. Just like most Windows, Mac, or Linux apps have a similar feel within their own OS we ought to do the same. The best way to keep the look and feel of apps the same is to use either OS or shell calls to draw windows and other UI elements.
- Keep backups of your projects! This cannot be stressed enough. Store updates frequently on multiple computers, on flash drives, online, or in that cloud thing. One thing I recommend is forming an account on GitHub (https://github.com/). You can keep your projects in an online repository and it can also make distribution easier too. Many major open source projects are also stored here including the Linux Kernel which it was originally designed for.
26
« on: October 30, 2011, 05:13:40 pm »
Do you mean to say zoomed as in a scaled sprite? That is doable but I think you would want to change that function to say Z_sprite(short * spr, int x, int y, int width, int height, float factor)
It is better to use a float there because the factor is often not an integer value especially if you want to shrink a sprite.
27
« on: October 27, 2011, 05:24:10 pm »
I think what you will need to do given the coordinates of the tool bench is to first generate a list of possible coordinates for each joint and then you can calculate the angles. Finding the angles is pure math but for finding possible coordinates you may have to use a guess and check approach. If given the tool bench coordinates the first thing you should do is find the distance between it and the base. Then knowing that each segment is 20cm and there were 5 of them that makes the distance 100cm when fully extended. With the comparison between the lengths then you can either approximate or exactly calculate what angles are needed to produce that distance using vector math. From there you could use a brute force approach to find to which joint each angle is acossiated with to match the original coordinates
28
« on: October 27, 2011, 11:29:35 am »
So, We must now convert theses functions, and change the sprites, right?
It's easier than you would think. The routines would stay mostly the same and the sprites can be kept the way they are. All you need to do is have a (short*) cast on the char sprite array and it can be used with short based routines. For example if const char test[8450] is your sprite, to convert to a short use short * newtest = (short*)test;
29
« on: October 27, 2011, 12:58:37 am »
I like how casio BASIC has all those string based functions similar to the high level ones found in languages such as C. I find them useful for heavily text based programs such simple CAS's and other math/science programs.
30
« on: October 27, 2011, 12:52:11 am »
CopySprite, and all thats use the Sprite Coder tool
I believe those are Kerm's old routines. The reason why he used chars was because they are guaranteed to be 1 byte on every C compiler while a short, though almost always 16 bits, is up to the implementation and we weren't sure yet what size gcc used for shorts yet on the SuperH. Now that shorts have been confirmed to be 2 bytes in memory it is safe to convert those routines from chars. It is also possible to use 32 bit int's or long's for a speed optimization at the cost of size. The reason why the size increases is because the code has to check for 32 bit alignment and if that condition is not met shorts must be used for the leading and/or trailing pixels. Plus if the sprites are small using int's or longs would result in a slower speed due to the alignment checking code. Because of this the only area where you would want to use 32 bit VRAM writes is if you can be guaranteed that the sprite is drawn in alignment (for example if you're drawing a background image) otherwise shorts are perfect for almost all drawing operations.
|
Show Posts
