I was kidding anyway Razz

Mostly, I think the lib compatibilities were a bit.. too far, but in the name of not starting a flame war, I shall desist in commenting further.

Here's a good feature idea: make the calculator smack its owner whenever the owner goes to suggest a new feature for DoorsCS Very Happy
Anakclusmos wrote:
++ on Kerm, i intended to make EchoOS grayscale, until i found out the timing.When using grayscale, your reduced to 1/3 of the time, drawing window and whatnot's very slow, and would be a hassle to control things like the mouse.not to mention, it would take twice as much data for everything, would hinder backwards compatability, and with DCS running as slowly as it currently is (no offense Kerm) it would be practically impossible
I was with you in that post up until the part where you said that Doors CS is slow. Can you specify in what regard you mean that? Specifically, what's slow about it?

@Keith: The BASIC libs, the ASM libs, or both? And I heartily agree with that last suggestion. Laughing
The xLIB/Celtic/etc compatibilities. The DCSLibs are a great idea.
(hypocrite) though i always thought onward and even posed some out there ideas of my own, I agree to some extent that DCS has gone a little to far.its rested too much on the gui and not enough on what really counts.A gui does not make a shell, a good shell would need 3 simple qualities...

Image Manipulation (like iPutSprite but MORE! people need things like being able to rotate,flip, and scale images.these would be definate plus in grayscale.)

Size management (it should provide simple ways to compact data as small as possible, offering a built compiler just for it to pre-compress the data before transfer, similar to pu-cruch)

Organization (the shell must offer and organized way to process date, such as ordering programs alphabetically or the way GBA renders its map modes
Anakclusmos wrote:
(hypocrite) though i always thought onward and even posed some out there ideas of my own, I agree to some extent that DCS has gone a little to far.its rested too much on the gui and not enough on what really counts.A gui does not make a shell, a good shell would need 3 simple qualities...
I'm having a hard time being respectful in my disagreement with you. Roughly 34KB is devoted to libraries, runprog functionality, folders, recovery and redundancy libraries, and more. I'd estimate at most 12KB goes into the GUI system, the desktop, and related functions. I recommend you spent nine years working on a shell and internalizing the massive amount of support functions required to run every time of available ASM and BASIC program before criticizing the shell for "resting too much on the GUI".

Quote:
Image Manipulation (like iPutSprite but MORE! people need things like being able to rotate,flip, and scale images.these would be definate plus in grayscale.)
That's what third-party program and Appended Library Extensions (ALEs) are for.

Quote:
Size management (it should provide simple ways to compact data as small as possible, offering a built compiler just for it to pre-compress the data before transfer, similar to pu-cruch)
Again, you're welcome to implement that as an external library.

Quote:
Organization (the shell must offer and organized way to process date, such as ordering programs alphabetically or the way GBA renders its map modes
There's nothing that the shell MUST do or that I MUST do. Please don't treat me like your feature slave. Also, I don't understand what you're requesting here.
regardless of the specs, you strive too much for compatability and less for function.if you write a better PutImage routine dont use iPutSprite as well, its a waste, and while you provide for the past, you hinder the future

wow.. another phrase for my sig...

sorry if i offended you, in general, my opinion is that there are too many uneeded things.not just focusing on the gui.By organization, i mean easy ways to perform much needed tasks like math or drawing objects in games that some people may have trouble with.

yes, SE's and ALE's could do that, but their difficult to make if you dont have a PhD
Anakclusmos wrote:
regardless of the specs, you strive too much for compatability and less for function.if you write a better PutImage routine dont use iPutSprite as well, its a waste, and while you provide for the past, you hinder the future

wow.. another phrase for my sig...

sorry if i offended you, in general, my opinion is that there are too many uneeded things.not just focusing on the gui.By organization, i mean easy ways to perform much needed tasks like math or drawing objects in games that some people may have trouble with.

yes, SE's and ALE's could do that, but their difficult to make if you dont have a PhD
They're also difficult to find time to make if you're working on your PhD. Smile I feel like everything in terms of math functionality is more than sufficiently provided by the TI-OS. If I were to only allow Doors CS ASM programs, then yes, I could dump a lot of ancillary libraries. If I removed the Celtic/Xlib libraries, I could dump another 12KB to 16KB of libraries. However, my overarching goal in creating Doors CS was creating something with universal appeal, something that would let you run everything, something that would be able to enable amazingly awesome programs (CALCnet, GUI libraries, AP libraries, for example) with relatively little effort from the end programmer. Unfortunately, that burden then shifts onto me to write a great set of powerful functions and libraries.
I can see why DCS might loose some publicity but overall the idea remains a strong subject.Make a shell with the best of the best routines and make a best of the best shell.

For example, my CheckKey routine.iz friggin awesome.Solves issues with multiple keypresses and is so simple a caveman can do it
calcdude84se wrote:
Shmibs, DCS7 it's 3 pages IIRC.
KermMartian wrote:
...as calcdude correctly noted, it's 3 app pages.

derp Rolling Eyes
KermMartian wrote:
Anakclusmos wrote:
++ on Kerm, i intended to make EchoOS grayscale, until i found out the timing.When using grayscale, your reduced to 1/3 of the time, drawing window and whatnot's very slow, and would be a hassle to control things like the mouse.not to mention, it would take twice as much data for everything, would hinder backwards compatability, and with DCS running as slowly as it currently is (no offense Kerm) it would be practically impossible
I was with you in that post up until the part where you said that Doors CS is slow. Can you specify in what regard you mean that? Specifically, what's slow about it?

the only thing i would call *slow* is moving between subfolders(and that can pretty much be attributed to the calc having 4-5 hundred times less processing power than a desktop pc). still, this isn't even really an issue because the majority of the time the function a user wants(i.e. writing down homework, playing games, ...) will be accessible from the subfolder he was in last... which is automatically opened on startup Laughing
Exactly! Yet another example of a helpful feature that I implemented at the suggestion of my dear beta-testers and bug-finders. Smile Not to mention that the HomeRun feature makes running any program as fast as finding it in the PRGM menu.
Yes, everything is perfect with DCS, I really don't see why you guys need more x.x
qazz42 wrote:
Yes, everything is perfect with DCS, I really don't see why you guys need more x.x
That's more or less my view as well (other than CALCnet, of course). Smile One thing that would be very helpful at this stage would be for some ASM programmers to volunteer to help me optimize DCS.
Does DCS 7 support the highres 16-shade screen of the NSpire?
DCS supports the screen, but it doesn't use all 16-shades since DCS isn't really coded for the NSpire.

In fact, I think the NSpire is different than the line of calcs DCS is coded for.
It is a TI 83+/84 application and does not run on an Nspire, but it can run in the 84 keypad.
As Souvik and comicIDIOT correctly note, it runs on the Nspire under the TI-84+ emulator, which means it sees the screen as if it was the same monochrome LCD that the TI-83+ and TI-84+ series have.
new ideas:
1.) Allow costome pics on ALL programms (i think it is possible, can be saved in the app var)
2.) Allow making asm programms!
3.) Password protection
4.) Make it somehow faster, loads a bit long on the 84+ with scrolling and opening Folders, even thought everything is in ROM
I see #2 having some form of potential, as there is an on calc compiler already, if I remember correctly.

#3 already has an SE, http://www.ticalc.org/archives/files/fileinfo/428/42827.html

#4 It doesn't take that long to load unless you have tons of programs it has to check. I believe it has to refresh itself every time it starts due to possible changes to the VAT that might happen while DCS is off.
If you turn off sorting, DCS loads much faster especially if you have a lot of programs.
how do you turn sorting off? its not in options menu...
  
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 2 of 3
» All times are UTC - 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