I have DODGEIT (not sure if I submitted this already). It's 2 KB, but that's standalone. (There's a menu and help and such!) Should I submit that (if I haven't already)?
Sorry for a late reply - I've been busy the past few days, with occasional time (5-10 min) on Facebook and the likes.
Thanks for all of your feedback! I really appreciate it! (This doesn't mean that you should stop - I need more feedback! ) I'm interesting in hearing the developer side of things - will you use it? Does C2I have everything you want? Is there anything missing? Any suggestions?
I think you should seriously consider continuing it for 2 reasons, the first being as you said, it is fundamentally different than gCn, in that is more an Internet connection deal, while gCn is more just a way to extend Cn to more than just a LAN, with indirect consequences leading to being able to be able to access internet resources if the server endpoint is configured correctly. The other one is the fact that you plan on having some sort of app, but also an includable version for developers, which, in my opinion outweighs having to have the weight DCS if you really are only using for that one program which might not need DCS otherwise. I could be wrong though, if that all sounds uninformed and stupid, please disregard
You're pretty much right - probably the only thing I will add is that it's not just a server endpoint - the client part can let the calculator access any server/website directly. (It's not just calc to another calc on the internet!)
Paired with CalcBox, it is Plus the ability to get apps directly to your calc, socialize, and others. But it's your opinion - what are the disadvantages?
WOAH That seems interesting, but not sure if normal users would use it (my friends went 'WTF?, Why would you need that? You're such a nerd!'). So yeah maybe.
Ehh... not really. My friends tend to be very interested in having Facebook on their calc. Explain that part to them, and then they might change their minds.
(Oh, and being on this site constitutes you as a nerd. No ifs, ands, or buts! )
I think that people would use a Calc-to-Internet for two reasons:
Because they don't have ready access to a computer (e.g. they are in a classroom)
Because it's freakin cool!
To make this really useful, you would probably want a Bluetooth or WiFi adapter to connect to the link port so that you could access the Internet wherever, such as in an airport. However, this could have possible reprecussions, like graphing calculators becoming banned from the SAT.
Ehh... that depends. You would need CalcBox; otherwise, the other way is via computer (USB cable). The way CalcBox works is that it handles all the wifi stuff (the calc would die trying to! ). Then a stripped down (no GUI, text display interfacing, some slight modifications, etc.) C2I and gCn is included, and you can launch either of them to enable internet via calc.
And no worries about the testing stuff - unless you stuff the CalcBox inside the calculator, there's no way for it to be banned. The other way (tethered to a computer) is obviously impossible to do.
normal users... what are normal users... i am not a normal user and i will use it for sure!
Yup, normal users wouldn't, especially if it required extra pieces :S
Not really - if it meant accessing Facebook, plenty of users may shell out some cash. My hope is that it won't be expensive - my imaginary thoughts say $1, but my guess would be < $10.
One issue that sometimes arises is people under 18 who have parents that disallow them to buy stuff online, but have no access to the required equipment in local stores or have access to it but the store sells it for $100 higher. It also needs to be simple to setup, otherwise only people experienced with electronic (or willing to learn that stuff and mess with wires) can use it.
I don't think I'll sell this in stores (it would be kinda awkward and I might run into legal trouble). I know what you mean by the high prices - countries other than the U.S. tend to have higher prices due to importing costs and such. If I ever sell this in stores, I'll keep that in mind. As for selling it, I plan to do a "peer to peer" sale type of thing - a person that can buy things online can sell it to others with cash. As I've said above, it should be pretty cheap.
Finally, it's a finished product. There's no "setup", unless you include turning it on, pressing a few buttons, and connecting your calc. The other way of connecting (which I should really emphasize) is via a regular USB cable. (Graphlink, Directlink, etc.) In the future, I will probably support serial/parallel port cables. (It's not too hard once I establish a set protocol.)
(If people are interested in building it, which I find tricky to do, I don't mind and will in fact release HW specs for others to build. Otherwise, for the majority, they'll buy CalcBox, a complete product ready to use! )
Netham45 really gotta add a bot relay system so when his bot disconnects, another by someone else takes over, or at least auto-reconnect and netsplit detection.
That'd be nice
Didn't alberthrocks have an OmnomBot for backup? Or was that for SpyBot only?
It's back up now, but not very stable. And Omnombot was only for spybot.
Wow... I never thought people would remember my bot! OmnomBot was a very old bot that was a replacement for SpyBot, as DJ has said. The major difference is probably TinyURL shortening vs. the new one, the programming language, and some other random things. Most interestingly, there was an experimental feature I added in. If you look in my code, there is "minion" code which lets you run a bot that does nothing but watch, and when the main bot dies, it comes in. The minion mode can be enabled, and the bot still would work properly, even when there's no other bots there! (So if the main one comes online, it can either be a minion and wait, or instantly jump to what it's supposed to do.) [See code: http://code.google.com/p/atombot/source/browse/trunk/AtomBot-OMNIMAGA-testing.py (188-206, 245-249, 780-927)]
Obviously, I'm not working on this code anymore, but anyone (especially Netham45) can take it and adapt it! Do note though - only distribute the final bot to trustworthy people. (Typically admins/mods) The bot code may be manipulated by others, and if given ops, can wreak havoc, which is why I give caution.
For now though, I think an infinite loop kind of thing would be fine for a bot "respawn" until this feature gets implemented.
C21 as C21 textures? Yeah, the future, simple and pretty!
C21 as in Calculator to Internet, I don't know... It can be done, I'm sure but is it that important? Most normal calculator users wouldn't use it, since it doesn't have many obvious advantages.
Paired with CalcBox, it is Plus the ability to get apps directly to your calc, socialize, and others. But it's your opinion - what are the disadvantages?
Hmm I have mixed feeling about this. If by user-friendlier you mean for example that on the TI-84+ you wouldn't need any extra hardware such as an arduino and just connect through USB, then it might be nice to see this come to fruition, but on the other hand, Kerm is still actively working on gCn, so maybe in the future he will have implemented that. Also, gCn and CALCnet projects have been in the works for years now (despite a hiatus around 2008-2009), so not only it would be kinda odd to some people to see a project by a Cemetech staff compete directly against another Cemetech staff's, but the fact Kerm has thought about gCn and worked on it every now and then since years ago tells me that this was a really ambitious project, and that you'll effectively need a lot of experience in calc programming and networking to get internet on your calculator.
On the other hand, I guess maybe you could join gCn development to help with new ideas and features. Regardless, if you decide to take on a gCn-like project, I wish you good luck.
That said, I wonder if this is in any way related to your calc server project a few months ago? I think Graphmastur was working on it with you, right? http://ourl.ca/6452/104579
Nope - I mean user friendly as in easy to use, with social networking built in and such. Plus that too, but as I've said, he's actively working on the USB port gCn.
As for the staff thing.... I guess you could say I'm part of the staff, even though I rarely moderate the forum, since there's hardly any nasty disputes in there. I doubt though that they would see me as a staff there, since I don't usually exercise my moderator powers.
The only way I will continue this project (or rather, start it) is if people are interested and are willing to use it. Otherwise, it would be a waste of my time.
And regarding the old topic, it is a deviation from it, but the concept is the same graphmastur has said that he is a bit busy with other things, and that he's uncertain about C2I's future in regards to competition, usability, and such, which is why I've posted this topic.
Does anyone have any other opinions about C2I? I'd really appreciate it!
EDIT: modified post to remove Scout's massive image
As time goes by, it seems anything could change. And it has - tons of development has occurred! From Axe Parser to particle simulation games to calculator networking, possibilities seem endless!
However, a previous project that has not taken off yet is now in hiatus. That project would be C2I.
C2I, as you may have guessed, stands for Calculator 2 Internet, and is a project to obvious connect a calculator to the Internet.
Since CN2.2's creation, C2I's role in creating the link from calculator to internet has gradually been diminishing. gCn v1.0's release truly made C2I feel irrelevant, since there's already a framework to build on. Quite a few nice games have been created with CN/gCn. With KermM's development to make gCn (and CN) available via USB, C2I's future is unknown... which is why I've posted this topic.
gCn and C2I are fundamentally different - gCn links the calculator to a virtual server hub via a client emulating a hub (with internet, of course), in which people can engage in multiplayer gaming or chat/IRC from there. (I'm not too sure how hub selection works, or if you can connect to a specific calc on the internet.)
C2I, on the other hand, had plans to be a bit more direct - basically, the client itself can do local connections, i.e. directly connect to IRC, the web, etc. However, it's not too far from what gCn aims to accomplish, and the methods of doing it. The only significant difference is that you can grab HTTP URLs in the calc, as well as manage sockets. (You're a bit more "direct" with connecting, so to speak.)
C2I was more or less envisioned to be kind and user friendly to the average user - it would have an app store, Facebook/Twitter access, a browser, etc. But with a browser planned and more for gCn, it seems to be very redundant in making it.
I have absolutely no idea where to go with this project. On one side, I see the missing bits of gCn and the design, and want to fill in the gaps with C2I. On the other hand, it's likely that gCn will progress (both calc and client side) to fill in the holes, which will make C2I eventually deprecated. Also, it's unknown whether people want to even use C2I at all in their projects, and if gCn could already do what was planned for C2I.
This is the original feature/implementation list of C2I:
Spoiler For C2I Features/Implementation List:
Framework/Implementation Core: = C2I works with any cable that connects the calc to the computer = 2nd or 3rd level connection (calc s/r raw data <-> client s/r raw data <-> Internet; OR calc s/r action calls <-> client s/r calls <-> client or its plugin parse/s/r/ raw data <-> Internet) = 3 parts: calculator, client, network/internet = LAN connection and interaction via client = Internal social core, with friend lists and groups, as well as "calc rooms" = Distributed as an application - is executable with settings, social core, etc., and acts as a library too for programs = Also can be bundled in as a program via source/binary inclusion Calculator: = Graphical, user friendly center with access to settings, social core, etc. = Request connections to server, send/recv. data, invites, etc. = Internal settings for server selection, username change, etc. = Integrated connection manager - dialog shows if connection is lost to the internet = Application or program distribution = Can either indirectly indirectly or indirectly handle data (see above connection text diagram for reference) = Sync settings with client Client: = At its heart, CLI only, but due to the needed user input sometimes, robust GUI will be included = Manages the connections to the server, data x-fer between calc and internet, etc. = Handles sockets, HTTP requests, etc. as needed by the calc program = Plugin support - plugins for handling "special" data (and sending them too) - basically pre-processing data if the calc can't handle it, and sending new data back into the calc. = Handles any LAN connections and can manage a mini server = Calc settings are changable - syncs settings with calc Server: = Manages connections and users = PHP based for easy handling and access (some places only allow outbound port 80), but faster, direct IRC like handling is also available via a different port = Data storage via MySQL and data files = Storage of files as necessary (if program needs them) = Maintains any online worlds or battle comm. = Plugins can be written to accommodate "special" cases, such as distribution of an online world, handling battles, etc. (this is not necessary to have an online world - again, "special" cases) = Online repository (optional), any language works as long as it implements the spec!
Developer/User Access and Features Developers/API: = Send/Recv, either when wanted or via interrupt = Choose different servers to connect to if the default isn't used = Can ask C2I to present an interface to connect to internet, choose person to play against, choose group, etc. = Store/get user data either on the computer or online (in the user data) = Store/get regular data on computer or online = Create invites/requests to send to other people to battle, chat, etc. = Perform HTTP GET/POST requests = Some preliminary, basic socket handling = Others??? == Some applications of API: === Online virtual world - fetching tiles from online asynchronously or not === Social integration - leaderboards, chat, FB/Twitter posts, etc. === Individual and group "battles", with invitation sending === CalcSVN - storage (and backup) of code online (programs, appvars, etc.) Users: = Browse the web = Access and update your Facebook or Twitter = Chat on IRC = Game "achievements" - with online leaderboard, and posting to Facebook/Twitter = App Store (name subject to change) - easy to use place to get other apps and programs. Not restricted like Apple's, and supports dependency linking (??), updates, and multiple repositories (the main ticalc.org repo, Cemetech repo, Omnimaga repo, etc.) = Online and multiplayer gaming
You can tell that it looks more fun on the user side of things, eh? With a fun developer gone (or is he? ), I will need significant help on the calc (and partial client dev help) to complete this project... if there's even a reason to continue.
The question to you guys is this: should I continue on to develop the API, etc. of C2I? Or is C2I just redundant? Would you guys ever use it? If so, what for and why? Are there other things you would look for in either gCn or C2I?
If you're making 3D games, you probably shouldn't go with python. If you really want to use python, the only package I know how to use is OpenGL.
I somewhat agree here, but I think OpenGL usually compiles the graphics, and then displays which shouldn't be too much of a problem. Of course, C would make a game significantly faster, but you can do that porting later when you've worked out nitty gritty details.
Oh, and don't use C++ to code your game. It's a pain, and a headache to debug.
Mixing python, SDL, and openGL seems to be an interesting mix. Of course, if you really don't want to play with raw stuff, Panda3D (does it have Python??) and Ogre3D (same as before) may be things to use.
I'm also assuming you have a 3D designer already (and won't do all the point plotting yourself), right?
The development version is most likely what the first preorders are gonna be and is the version which the developers in the community will use to develop the software for this calculator. The development version is basically the same as the Professional version, except it lacks WiFi and the integrated battery pack. This will keep the costs under $200 which is what you guys seem to want. The WiFi module and integrated battery is just too expensive I believe for most of us now anyway. I need to think about it more and look around if I could make it any cheaper. If you decide to preorder a development version and you really want WiFi though, you may be able to add in WiFi later on using the expansion port built into the calculator.
Let's keep the Wifi for professional/dev version. One of the things is that the "Pro" version will (and must be) designed differently. Here, you're aiming for a VERY (and I mean VERY) sweet spot - scientific research. Besides it being a calculator, it can also become a sensor for data collection! (Scientists have used the iPod Touch a LOT for data collection - via not so pretty ways, mind you. The headphone jack comes to mind...)
The "expansion port" must be standardized, or have open specs on usage. Otherwise, it won't look too appealing. Also, the "pro" version should be pretty thin - the physical keypad can be hidden under the touchscreen and pulled out as needed.
I'm thinking of making the Professional version have a portrait display (240x320), with a smaller and simplified keypad to compensate for the cost of the WiFi module. However, programs and software that are dependent on how the screen is rotated would be affected. I suppose you could rotate the Professional version by 90 degrees if you need the landscape orientation.
For what purpose? I'd think it could be multidirectional if needed. Again, it's all about software and a bit of GFX acceleration to perform text rotation. Regular can just be locked to landscape, but pro should have an option. Remember, we're not making an iPod Touch here!
How open will this be? Will you document EVERYTHING? Also, how does the flash chip and such work? Do you have to erase entire sectors of stuff to get it to flip a 1 bit to a 0 bit?
All the hardware is taken care of by the Linux kernel. You can look at the kernel sources and the drivers I've written when I get around to uploading them into a repository. Pretty much, programming this thing feels just like how you would program your computer. You can write your programs in Java, Python, C/C++, whatever. You don't need to depend on any SDK or hack it to get some code running. It's that open. If you have questions, I'm here and will be glad to answer them. That being said, you don't really need the schematics as they are not necessary to do programming for this calculator. You guys have been able to program your calculators, computers and laptops without any schematics as an example. Also, I don't want clones or cheap ripoffs being made. It would make all the effort, time and all the money I fed into the project a waste.
I can respect your decision here. Software is pretty easy to make, and will be FOSS, but HW is a bit on the edge. I do ask though that you provide a standardized expansion port. If not standard, provide open specs and examples. Any interfacing and such with the USB must also be open. (This includes charging, etc.)
@alberthrocks: This calculator will downclock itself since CPU frequency scaling is supported in the Linux kernel. The new processor which I plan to use will even go a couple of steps forward and disable and power down certain blocks of the CPU when the hardware is not in use further using less power. Plus, it's also manufactured on a smaller die. You will also have the option to turn off the backlight and dim the brightness of the LCD.
Ahh, but it *won't* downclock itself automatically. It's SUPPORTED, but not really "turned on". You will need to download cpufreqd or cpufrequtils, and play around with them to get true support working. THEN you'll see that battery life improvement.
As for the power down of the screen, backlight, etc... a couple of things: - Aim for a non-reflective screen. They're annoying, and if you execute it properly, you can get the backlight off (or almost off) and still be able to see the screen in a classroom. - A daemon will need to be written to control this. - For powering off... --> If left on standby, screen should fade down in 30 sec - 1min, then the screen should turn off in 30 sec - 1 min, then go to sleep in 1-2 minutes, then hibernate in 5-10 minutes. --> If turned off via button(s), screen should turn off immediately, and the system can go to sleep in 30 sec - 1 min, then hibernate in 3-5 minutes. --> These settings are all user controllable. The numbers specified above are pretty conservative - the software should practice aggressive power management. It must be better than the Nspire AND the iPod Touch at battery life. Reason? Obviously, for the calc market, better life is a good thing, and then if an iPod Touch that plays music, surfs the web, etc. continuously beats this.... then it's obviously not a good thing either. (iPod Touch can do 40 hours of continuous music, not sure about Nspire battery life.) Of course, the iPod Touch has a decent battery inside, so we'll be a bit nicer.
As for a testing mode, I have to think more about that. The problem with this calculator is that it's just too open and flexible, software wise. I'm pretty sure whatever "lock" I can place on this calculator, someone will find a way to circumnavigate it. What I could do probably is place in a hardware switch that shuts off power to SD slot and expansion port, disables the USB and disable access to some regions of Flash memory with an LED indicator that the switch has been flipped.
Ahh, that's like saying all FOSS is insecure because they're open source/HW, eh? Case in point: OpenSSL and OpenSSH. Both are purely FOSS, and a quick search yields the source code in seconds. But as much as you read it, it's pretty impossible to hack it. And for exploits that have been found - they are found by the best security researchers in the field, not some amateur hackers like us.
You get my point here, right? Here are some ideas: (can be combined or separate) 1) Separate the testing mode into a immutable flash chip, and with a simple HW flag (and a file on the data side of the writable chip), lock it as such. This needs LOTS of testing for the testing OS, since it can't be changed afterwards.
2) Have a encrypted signature check just to see if an official OS is installed or not. If not, turn on a flag that indicates a third party OS is used and warn the user that installing the OS will make the calculator unusable on the test.
3) The bootloader has a hook that when the keys are pressed, takes over the display and shows the dialog asking the user about going into testing mode. This replaces the OS's key detection, and can be used with #2.
4) Lock the test lighting with an AVR/some little chip with encryption and such, and the testing OS can only access it. (This seems to be a bad idea...)
Seems cool, but for the standard version would the audio jack always remain disabled with no way to enable it? If so, then it might be best to just not put any audio jack at all in that version.
As for the different screen on the pro version I think it should remain compatible, although I guess the screen could be rotated, assuming it's not too hard to play games and use software with the calc sideways. X.x
Seconded - I/O ports are an oldie these days. See below for my opinion on screens...
I hope that the "ultimate" version will have compatibility with programs for the less powerful calc versions that use the keypad/screen in unique ways.
And a rotatable screen would be nice. Incompatibility is not very well liked in the dev community, and you want a lot of people to adopt it! (The scientific people in general are watchful for compatibility, and doesn't take anything but it.)
Well java would be cool since some people like it. Ashbad do you mean it's only available on one of the 3 Project Paradise calcs? I am confused
I think Java is just as a portal to the innerds of UberCalc, including the interface, I/O, and possibly the math part too. However, Java is NOT to be used as the core. It's not very pretty if it's just used for everything, since it's pretty slow, especially without ARM accelerated support. Android is an example - you need at least 1 GHz to have a jitter free experience.
I'm assuming that you will go over how to create a cross-compiler for C? Java might be a little much, unless the ARM processor supports it natively.
Yes, I plan to have a wiki by the time preorders are ready. As for Java, I've been using OpenJDK and all the Java programs I ran seem to run fine on the first prototype. The final design has a faster processor and more RAM, so everything should be ok. Plus the processor has Jazelle. I'm not sure though if OpenJDK supports Jazelle.
@DJ_Omnimaga, I think Ashbad was referring to graphmastur's post. All three versions will be software compatible with each other.
Some good news, I might be able to get funding to build a prototype of the final hardware design soon. This should be exciting as it will be a good indicator of when preorders can start. I will keep you guys updated.
Java is OK as long as you don't use it as a core or GUI. I would stick with Python or C/C++.... heck, I wouldn't even recommend Python! You have to have a fast and stable core, and then branch out with APIs for languages like Java, Python, Perl, etc. (and of course, BASIC! ) We emphasize on the speed factor here as it's part of the marketability of this product.
Will the final product be fully touchscreen? If so, you should make it iPod Touch like, sans restrictions and only for educational purposes. (Teachers hate everything, typically.)
I was thinking of making two different versions of Project Paradise, one that's compatible with College Board testing standards, then one hardcore version for the ultra nerds (WiFi, touchscreen).
Ahh, so educational edition and hacker edition. Nice! But make sure to hide the hacker version somewhere in a "Dev/Hacker" section - you don't want teachers or testers to think that it's evil.
I suggest getting familiar with Clutter (http://www.clutter-project.org/). It's a very decent UI framework (note I say UI, not GUI/toolkits). Key to having success in this field is a good GUI, and Clutter can do that for you.
I'll take note of that. When I finish the hardware, we can decide to put whatever software we want onto it.
Good plan. Also, I'm pretty sure you'll make it pretty and not use the standard GTK theme.... right?
- Same or even better battery life compared to a TI-83/84 is a must!
Eh... that's gonna be really hard (maybe impossible) to accomplish. My prototype currently runs on 4AAA rechargeable batteries rated at 850mAh and it's getting about 20 hours before needing recharge. However, my final design will utilize a newer processor manufactured on a smaller die, thus it's more energy efficient. I had a couple of extra stuff on my prototype, so factoring in new faster hardware and removing the extra stuff, you might at best get 40 hours. Hopefully that's good enough. The hardware in Project Paradise is just way too powerful compared to a TI-84 to have the same amount of battery life.
Would it be possible for it to downclock itself when not in use, and maybe sleep/hibernate (transparently, of course) after a certain amount of time? (Screen dimming too would really help, or using a screen that can work off natural light?)
- Do not merely toss software onto the device (I'm sure you won't, but just as a reminder). You will need to find a way to wrap around the libraries with some seriously productive (and pretty) GUI. - Desktop clicking != touchscreen tapping. Be careful!
I just plan to make sure I can get the hardware working. I was hoping that when enough people have the calculator, we can develop all the software and beef it up together.
Ahh, so your plan is to basically make prototypes, get that finalized, and then with the power of FOSS create decent calculator software. Sounds like a plan to me!
- It should be AA/AAA battery powered to keep with current standards (and habits, per say)
It can run on AAA batteries. However, I was thinking of placing a Lithium Ion battery pack (with a high energy capacity rating) inside the calculator. That way, it'll have a longer battery life than typical batteries (thus lessening the battery life problem above) and can allow the calculator to be recharged over USB.
Maybe a AAA/internal batter pack fusion? It depends. My suggestions above may or may not decide this.
One negative about the battery pack is that if it runs out, and you forget to charge it, there's no way to get it on. (Hence my "fusion" idea)
This is a very decent idea and hardware! If this becomes successful, we will back it up (and maybe make it OTARM?)! And speaking of that... you must be an expert at this stuff, as you've developed hardware all by yourself! Could you please assist us in the summer for OTZ80 and OTARM? (Obviously, 2 calculators - one powered by Z80s, another by ARMs!)
If my project takes off, I can use the resources to fund your projects. If I have the time, I can help you build prototypes, and manage the testing and production if you want.
We would be grateful for your support! Pending community decisions, we could just back your project in replacement of OTARM. (It all depends - my only reason for doing that is because I don't think 2 indie competitors against each other and the big guys would work too well! ) If OTARM does go on, we'll probably use the software developed, remove all the touch-screeny stuff, and modify it to be for buttons only.
Just curious though - you're obviously in college, but what level? (Freshman-Senior, maybe even beyond? Or professor? ) And I'm guessing you're in the U.S. as well?
Just noticed the comments below and realized you answered that question...
Finally - is this project for educational purposes (a project a school?) or just for fun?
Both: for the community (fun) and an engineering project. I've been in the calc community for years and haven't really seen much progress on how calcs evolved. I thought it would be cool to build an ubercalculator and maybe other people would want one too. I'm also college student majoring in computer engineering, so even if the market doesn't have a place for this calculator, it make an awesome senior project (a requirement here at my university to get your degree). It works both ways, so I don't really have anything to lose working on this project.
Ahh, that means it really should get a decent GUI! The key to a device's success isn't just power - it's ease of use too!
Another idea I had, if I can make some prototypes of the final design and make sure they work, would anyone feel safe pre-ordering with a 2-3 week waiting time (for manufacturing)? I was thinking that if at least 50 people preorder, it'll be considerably cheaper than having each one built one by one. Would you guys just want the board (with LCD and keypad of course) or would also like an enclosure with it? I'm confident I can at least get some prototypes of the final hardware working by June.
Hmm, I'm really getting confused - keypad AND touchscreen? or is this touchscreen only? Pre-ordering is actually a key way to getting boards and prototypes out, so this is a must. An enclosure is a must - it doesn't have to be the final product, but it should stay in a box. Electronic care outside of one tends to be destructive at times.
Also, we might set up a "trust" fund (if you call it that way). Basically, any serious dedicated testers can get one for free if they commit to reporting bugs, keeping the prototype alive and well, and help out with the development.
Finally, to add more suggestions.... - SECURE the device. Not brutally lock it like Apple though. What I mean is to have a special "testing mode" (much like TI's), but make sure it's uncrackable. This could include a non-writable chip with the proper data to set one up. You might also wish to have a "testing mode indicator", but DON'T copy TI-Nspire's one. Make it interesting too - nothing boring, maybe even accessible by developers! Finally, if the device supports OS replacement/upgrade, make sure there's something in the OS that indicates it's authenticity. Remember, acceptance into schools and testing environments is a must for this kind of stuff.
- "School mode" Just a random idea - maybe a "school mode" to disable access to games and internet? Not sure how that would work out though, and when to unlock.
- Audio? Probably not a good idea, but I'd like to see your opinion on it. This is also leaning towards a I/O port suggestion, but that may seem like a step backwards.
Will the final product be fully touchscreen? If so, you should make it iPod Touch like, sans restrictions and only for educational purposes. (Teachers hate everything, typically.)
I suggest getting familiar with Clutter (http://www.clutter-project.org/). It's a very decent UI framework (note I say UI, not GUI/toolkits). Key to having success in this field is a good GUI, and Clutter can do that for you.
A couple other things: - Same or even better battery life compared to a TI-83/84 is a must! - Pricing should be under $160 due to competition prices. - Do not merely toss software onto the device (I'm sure you won't, but just as a reminder). You will need to find a way to wrap around the libraries with some seriously productive (and pretty) GUI. - Desktop clicking != touchscreen tapping. Be careful! - It should be AA/AAA battery powered to keep with current standards (and habits, per say)
This is a very decent idea and hardware! If this becomes successful, we will back it up (and maybe make it OTARM?)! And speaking of that... you must be an expert at this stuff, as you've developed hardware all by yourself! Could you please assist us in the summer for OTZ80 and OTARM? (Obviously, 2 calculators - one powered by Z80s, another by ARMs!)
Finally - is this project for educational purposes (a project a school?) or just for fun?
Pete Shinners' wrapper may have cool alpha effects and fast blitting speeds, but I have to admit my favorite part of pygame is the lowly Rect class. A rect is simply a rectangle - defined only by the position of its top left corner, its width, and its height. Many pygame functions take rects as arguments, and they also take 'rectstyles', a sequence that has the same values as a rect. So if I need a rectangle that defines the area between 10, 20 and 40, 50, I can do any of the following:
rect = pygame.Rect(10, 20, 30, 30) rect = pygame.Rect((10, 20, 30, 30)) rect = pygame.Rect((10, 20), (30, 30)) rect = (10, 20, 30, 30) rect = ((10, 20, 30, 30)) If you use any of the first three versions, however, you get access to Rect's utility functions. These include functions to move, shrink and inflate rects, find the union of two rects, and a variety of collision-detection functions.
For example, suppose I'd like to get a list of all the sprites that contain a point (x, y) - maybe the player clicked there, or maybe that's the current location of a bullet. It's simple if each sprite has a .rect member - I just do:
sprites_clicked = [sprite for sprite in all_my_sprites_list if sprite.rect.collidepoint(x, y)] Rects have no other relation to surfaces or graphics functions, other than the fact that you can use them as arguments. You can also use them in places that have nothing to do with graphics, but still need to be defined as rectangles. Every project I discover a few new places to use rects where I never thought I'd need them.
10. Other collision detection methods
So you've got your sprites moving around, and you need to know whether or not they're bumping into one another. It's tempting to write something like the following:
Check to see if the rects are in collision. If they aren't, ignore them. For each pixel in the overlapping area, see if the corresponding pixels from both sprites are opaque. If so, there's a collision. There are other ways to do this, with ANDing sprite masks and so on, but any way you do it in pygame, it's probably going to be too slow. For most games, it's probably better just to do 'sub-rect collision' - create a rect for each sprite that's a little smaller than the actual image, and use that for collisions instead. It will be much faster, and in most cases the player won't notice the inprecision.
For cellular automata... some searching can be done for pixels. Or maybe.... you could create arrays with locations WITH the water! (It is weird, and that's the only idea I could come up with.)
# Python "water" pixel (cellular automata) code sample pixwaterarray = [] pixwaterarray.append([123,456], [111, 222], [333, 444]) # This should be populated with values that are isolated to a certain area to begin.
for arr in pixwaterarray: yloc = arr[1] # Lookup if there are pixels below it... nobelow = 1 for arr2 in pixwaterarray: if arr2[1] > yloc: nobelow = 0 if nobelow = 1: pixwaterarray.remove(arr) pixwaterarray.append([arr[0], yloc + 1])
# Then you can loop through the array again and then replot the pixels! :)
EDIT: I realized you code and post faster than me! You should make sure to do checks with files, such as the sprites. Also, if possible, include the sprite in question as an attachment!
Show Posts
(This doesn't mean that you should stop - I need more feedback! 
My prototype currently runs on 4AAA rechargeable batteries rated at 850mAh and it's getting about 20 hours before needing recharge. However, my final design will utilize a newer processor manufactured on a smaller die, thus it's more energy efficient. I had a couple of extra stuff on my prototype, so factoring in new faster hardware and removing the extra stuff, you might at best get 40 hours. Hopefully that's good enough. The hardware in Project Paradise is just way too powerful compared to a TI-84 to have the same amount of battery life.