Long have I bemoaned that despite the thousands upon thousands of hours of coding, testing, and marketing efforts I put into it, Doors CS remains the underdog graphing calculator shell. Although widely used in the programmer community, I believe that competitor MirageOS is still a household name in the larger international student community. I'm hoping with the TI-84+CSE, this can change, and Doors CS can take center stage as a shell for gamers and programmers alike. The biggest and most obvious changes will be modifying things to work with the color screen and higher resolution, but I was pondering what exactly this will entail, and what other features I want to improve or add. Among the things I've thought of:
:: Modify the desktop to be 320x240. Support 8x8 and 16x16 icons, but also allow 32x32 icons or larger? I could fit four rows of 32x32 icons on the new calculator's screen, and perhaps six columns, for 24 icons per page instead of 6. Should I try, or will this be unreadable?
:: Modify the GUI API to support the bigger screen and color. How? Which items will need changes or improvement? Should I try to support DCS7 programs at the same time via some kind of compatibility layer? Or is this a moot point, since almost all those programs also do direct-pixel accesses to the buffer? I'm thinking the latter. I also want to add a typing hook, something that has long been missing. Plus the ability to type in the spinner objects.
:: Improve CALCnet. Specifically, I want explicit hubs to be a thing of the past. Tentatively called CALCnet 3, this would support calc-to-calc USB, direct USB, and standard I/O networking. The clock-inhibit that signals a new frame would be shorter, so that calculators could differentiate between Cn2.2 and Cn3 frames, and that Cn2.2 calculators would ignore Cn3 frames. I know how frames could contain hub names for direct messages, but what about broadcasts? Would calculators subscribe to specific hubs for broadcasting? How do you prevent every gCn-connected calculator from getting every broadcast frame sent everywhere?
:: Offer new color-oriented features to BASIC programmers. Offer a compatibility layer for existing BASIC programs? Get other programmers on board to help make Doors CS 8 and above a reality sooner? I'd love feedback and especially offers of help!
Needless to say, this is still rattling around in my head, and the fact that I'm working on a PhD, a book, and some freelance code plus maintaining Cemetech and the rest of my projects doesn't help at all.
I think an example of what an 8x8 and a 16x16 icon would look like would be needed, though the 8x8 is doubled up to the 16x16 anyways, right? Or did that get dropped? I don't really remember much about the icon stuff anymore.
I'd really like to see what we would be looking at when running other programs on this particular calc before I make any other thoughts or suggestions.
32*32 icons sounds good to me(even though I don't know how you would do custom 32*32 in the TI-Basic, if possible). Also, I JUST IMAGINED GOSSAMER IN COLOR.
I'm a little confused about what you said about gCn/Cn. Did you say that 2.2 would be comatible with 3? Would you be able to play something like Obliterate with someone with a monochrome calc if you have a colored?
KermMartian wrote:
Long have I bemoaned that despite the thousands upon thousands of hours of coding, testing, and marketing efforts I put into it, Doors CS remains the underdog graphing calculator shell. Although widely used in the programmer community, I believe that competitor MirageOS is still a household name in the larger international student community. I'm hoping with the TI-84+CSE, this can change, and Doors CS can take center stage as a shell for gamers and programmers alike.
I think that will happen, especially since MirageOS is no longer being updated and will die with the resolution change. As the CSE becomes more popular, so should any new shell. Not to mention that ION will also be fried.
Quote:
:: Modify the desktop to be 320x240. Support 8x8 and 16x16 icons, but also allow 32x32 icons or larger? I could fit four rows of 32x32 icons on the new calculator's screen, and perhaps six columns, for 24 icons per page instead of 6. Should I try, or will this be unreadable?
I think that you should have some sort of zoom option to alternate between large icons (classic 3 x 2) and small icons (6 x 4).
Quote:
:: Modify the GUI API to support the bigger screen and color. How? Which items will need changes or improvement? Should I try to support DCS7 programs at the same time via some kind of compatibility layer? Or is this a moot point, since almost all those programs also do direct-pixel accesses to the buffer? I'm thinking the latter. I also want to add a typing hook, something that has long been missing. Plus the ability to type in the spinner objects.
I think that the proportions of the various GUI items, as far as I've seen, are fine as they are, and it will be very nice to have more precision with the higher res screen. And no, I don't think that a compatibility layer would be worth your time. I don't know what you mean by a typing hook, but while we're on the subject of typing, it would be nice to have "Aa" vs. "AA" modes in the Alpha switcher, as well as the symbol selection being a different key. And I'd love to be able to type in the spinners.
Quote:
:: Improve CALCnet. Specifically, I want explicit hubs to be a thing of the past. Tentatively called CALCnet 3, this would support calc-to-calc USB, direct USB, and standard I/O networking. The clock-inhibit that signals a new frame would be shorter, so that calculators could differentiate between Cn2.2 and Cn3 frames, and that Cn2.2 calculators would ignore Cn3 frames. I know how frames could contain hub names for direct messages, but what about broadcasts? Would calculators subscribe to specific hubs for broadcasting? How do you prevent every gCn-connected calculator from getting every broadcast frame sent everywhere?
You could create hubs through a simulated host-client relationship. Basically, an extra 5-byte field would be offered in the calculator's local storage for specifying the ID of a host. A broadcast packet will only be accepted if this field is all zeroes or if the sender of the broadcast packet is the host. (The host would set this field to its own ID).
Quote:
:: Offer new color-oriented features to BASIC programmers. Offer a compatibility layer for existing BASIC programs? Get other programmers on board to help make Doors CS 8 and above a reality sooner? I'd love feedback and especially offers of help!
A compatibility layer for BASIC programmers is totally possible, as long as they don't try to use libs that aren't included with DCS. Your libs could also include the appropriate color features as optional arguments.
Quote:
Needless to say, this is still rattling around in my head, and the fact that I'm working on a PhD, a book, and some freelance code plus maintaining Cemetech and the rest of my projects doesn't help at all.
And we understand that. Take all the time you need.
Also, I'm just going to plug for this a third time: Add ASM versions of malloc() and free() so that we can dynamically allocate memory (either in safeRAM or appvar buffers). I've spent the past few days writing my own simplistic implementations in C, which with a little modification can be compiled with SDCC and run on a calculator. I'll edit or supplement this post as soon as I can so that you can look at the code. And if you do this, I think that CALCnet would greatly benefit from requiring it to be set up so that you could queue multiple frames.
Suggestions:
-Chaining/compatibility with Zstart (at least on non-modded OSes)
-Chaining with xLIB 2 (see MaxCoderz)
-The ability to skip the introduction instantly without having to move your cursor down on the next button and click it. It would be nice on emulators in particular.
I'm starting to seriously consider having the desktop use a non-mouse-based interface by default, with some key to switch between a default TabFuncs-like interface and a mouse interface. Thoughts?
using Color Charts. as i mentioned on the SAX, you make something (as i would imagine it) like this:
Code:
Color Chart, 16 colors:
#color1
#color2
#color3
#color4
...
#color16
you might also use 2 sheets, one for the background and non-active sprites, and another for the active sprites.
And then this for sprite data:
Code:
DB Color+1,Color+2,Color+1,Color+1
DB Color+2,Color+2,Color+2,Color+1
DB Color+2,Color+2,Color+2,Color+1
DB Color+2,Color+2,Color+2,Color+1
when the sprite needs to look different, like your in a different place (Gamewise) or a new "Theme" has been applied, all you do is swap the Color Chart.
Edit:
2 things about the mouse idea:
1)Why? do people complain about the mouse?
2)sounds fine.
Actually, this brings me to something even more important. Other than getting the Doors CS GUI API working on the new calculator, what am I going to do about new ASM and BASIC libraries for the new calculator? It sounds like new color libraries will be the primary focus, but I don't know what other graphics help programs are going to need.
Edit: Luxen, to clarify, are you talking about ways to layer tilemaps on top of backgrounds, or what? And yes, people do complain about the mouse interface. I want to do whatever is necessary to make Doors CS be the most popular TI-84+CSE shell, and if it means making the desktop offer a more obvious mouse-free option, then so be it.
Edit #2: Maybe a big pair of buttons when you first start Doors CS, asking if you want a primarily mouse or primarily arrow-key interface?
I think you will be able to define a clearer direction for the colour aspects of DCS once more information is known about the hardware and in particular interfacing with the LCD. Since you will most likely require a screen buffer you may have to look at artificial resolution changes (maybe half-res 160x120?) should there be no existing screen buffer facility.
Another idea was the ability to have certain aspects of the GUI indexed to a global colour palette, which could enable you to implement 'themes' in DCS which could be defined [and distributed] by users.
Tr1p1ea, would you imagine those themes just defining color mappings, or would you also see them including custom sprites for various aspects of the interface (scrollbars, for example)? On an unrelated note, but since it's you: Doors CS will definitely need some color-related libraries, either to supplement or replace the existing libraries. Is that something you might be interested in helping to design and create? I know that your hybrid BASIC library expertise would be much appreciated, and any less coding I need to do in my busy life makes me saner.
Initially id imagine that it would just be colour mappings, however if you left the aspects of your controls monochrome you could possibly employ some masking techniques to colour them individually?
And of course id be happy to help out where i can
.
About the mouse: Yeah, I think that the mouse as it is is really an obstacle to DCS. All it really does is allow you a fancy method for clicking on targets, and it's pretty clunky if you don't have an actual mouse connected to the calculator. You can keep the mouse look, but it should jump between viable click points, kind of like navigating a DVD menu. And that also means that the flippers should have a different operating method (like a - button on the left and a + button on the right).
About the colors: Yes, I think that color libraries should be provided by DCS, although I still would wait on specifics until we know how the LCD will be operated.
And one more thing: I know I've said it before, but I'd love to have a heap implementation, perhaps one in which you call a subroutine to explicitly add available areas to the memory space that DCS can use. And the reason I'd love a heap implementation is so that CALCnet3 can require it so that you can store packets and queue them up (e.g. prepare all of your update messages to all appropriate players one after the other, instead of waiting for each one to send before making the next one). I'll finish that C code I've been writing with this in mind and post it to these archives, so that you can take a look at the specifics I'm considering.
Would it be viable to render everything at half resolution and then upscale it using an hqx or similar algorithm? As long as you keep the half resolution frame buffer in memory, you can re-apply hqx per-pixel as new pixels are added, rather than having to run over the entire frame every time it's pushed to the screen. This would solve many problems such as coordinate and memory issues while still looking very attractive.
It'd be a great opportunity to poll the community and see what kind of library features they want and need. One of DCS's biggest detractors is that it requires 3 App Pages, perhaps 4 with all the bigger screen on the 84C. This shouldn't be a *huge* problem but finding a magical way to fit it into 2 pages would be awesome. Removing key library functions could hurt program portability, and I think that's something we should heavily promote. Allow the GUI arguments to support color but if there aren't any color arguments then default to B&W; which I think would go a long way to ensure forwards capability from the TI-84+/SE and easy portability to the 84C.
But one perk with being the first would be that you'll get the downloads one way or another and people will realize DCS has all these great libraries for BASIC programmers, here's that chance to make it even better!
Question: Are you going to start from scratch on this, and create specific libraries as they are suggested? Obviously, with the opening of colors, you'll be able to add a great many new functions that previous libs didn't have.
And I know this was explained/mentioned at one point in the past, but I've slept since then and can't remember.. But, what's the possibility of making libraries SEs, which Doors can scan and see, and adds their functionality to its own, sort of? That way, DoorsCS can remain much smaller. Hopefully you aren't getting agitated with my repeated asking of this idea. :p
comicIDIOT wrote:
It'd be a great opportunity to poll the community and see what kind of library features they want and need.
Very heartily agreed. That's what I'm hoping to do, and hopefully we can find a way to get members of the other sites to weigh in as well. Quote:
One of DCS's biggest detractors is that it requires 3 App Pages, perhaps 4 with all the bigger screen on the 84C. This shouldn't be a *huge* problem but finding a magical way to fit it into 2 pages would be awesome. Removing key library functions could hurt program portability, and I think that's something we should heavily promote. Allow the GUI arguments to support color but if there aren't any color arguments then default to B&W; which I think would go a long way to ensure forwards capability from the TI-84+/SE and easy portability to the 84C.
That's part of the problem. I'm considering doing some sort of up-scaling for B&W GUIs and adding the requisite extra arguments for color GUIs, but as I was discussing yesterday on IRC, I'm really starting with a blank slate here. Almost every program will need to be ported or written from scratch, so I'm pretty much free of a lot of backwards-compatibility woes. I can toss out support for the Ion and MirageOS headers right off the bat, as well as the DCS6 header. I can design a new, very compatible header format that all shells can use. For example, calc84maniac very intelligently requested a BSS region to define scratch memory.
Quote:
But one perk with being the first would be that you'll get the downloads one way or another and people will realize DCS has all these great libraries for BASIC programmers, here's that chance to make it even better!
Absolutely agreed! And I'm hoping to get various community members who are more experts than me to weigh in idea/code-wise on key features, such as my overtures at Tr1p1ea about figuring out what color libraries BASIC coders need.
tifreak8x wrote:
Question: Are you going to start from scratch on this, and create specific libraries as they are suggested? Obviously, with the opening of colors, you'll be able to add a great many new functions that previous libs didn't have.
Not totally from scratch. I want to keep a lot of the old useful routines, as they are still useful. As far as we know, for example the VAT still works the same way.
Quote:
And I know this was explained/mentioned at one point in the past, but I've slept since then and can't remember.. But, what's the possibility of making libraries SEs, which Doors can scan and see, and adds their functionality to its own, sort of? That way, DoorsCS can remain much smaller. Hopefully you aren't getting agitated with my repeated asking of this idea. :p
Not agitated at all! I want a much better plugin system than the current SE system, but in order to figure out what it should include, I need to know what programmers want to add to Doors CS.
Lots of ideas on cemetech, but keeping space and functionality is important. here are my thoughts on...
...porting: while DCS 8 might include prebuilt capabilities, why don't you also think about having this library as just a shell expansion. sure, there may be tons of things we would all love to directly port to the new system, but as time passes, it will begin to be a not-so-popular idea. having it as a shell expansion means that it would be comepletely seperate, optional to the user.
...Color Charts:
[img="http://i48.tinypic.com/v6umw0.png"]
does this clarify what i meant? ive used this plenty of times befor in DOS programs, like the ohrdos game creator and VGAPaint.
...Adding things to Doors through SEs: Not sure how these work.
...the mouse: the Big Question dialogue box sounds like a fine idea. before doors shows it's help page, have the BQDB appear, so you can choose between mouse or highliting. personally, i love the mouse, but beleive it is a bit clumsy with only 6 programs per screen.
...icons for the programs: having it able to switch between tiny icons and bigger ones would be nice. scale 32s to 16s, but im not sure 8X8 icons are useful with the big screen. unless you use something like the windows explorer's "Details" veiw.
Well, there are definitely going to be more than 6 icons per desktop screen in this version, and I'm planning smoother scrolling, where you scroll one row (not one screen) of icons at a time. I don't really want to switch to a Details-type view, as I'd feel like I was basically aping MOS at that point.
i can understand that; i was only trying to think of a reason why you might still use 8X8 scaling in the new calc.
LuxenD wrote:
i can understand that; i was only trying to think of a reason why you might still use 8X8 scaling in the new calc.
Well, I don't want to discard the idea of BASIC programs using 8x8 icons, although I also need to canvas BASIC programmers and find out what size and palette of icons they want.