Post by: Halifax on February 25, 2007, 04:28:00 pm
The library as is right now includes over 30 functions and is compatible with Ion.
I am currently working on the API and have already implemented a FIFO queue stack and a queue handler. Which means the user can do what they want and the program / NexGenGS can do what it wants and then get to what the user wants. The queue records keys pressed,functions requested, and other things. This is a new and fresh idea to make it easier so that no data is lost and the program can move at the pace it wants to move at. This is another key point of NexGenGS. There are currently 10 API functions and many others on the way. A screenshot will be coming soon of the GUI and showing the use of the NexGenQueue?.
Note: No MirageOS support will be included because the libraries are big and useless and no one uses them anyways. Most programs only use Ion libraries. Another note is that this Game Shell will run BASIC, no-stub ASM,Ion ASM, and NexGenGS ASM programs.
Post by: tifreak on February 25, 2007, 04:32:00 pm
Post by: Halifax on February 25, 2007, 04:35:00 pm
Post by: bfr on February 25, 2007, 04:36:00 pm
*bfr
Post by: Halifax on February 25, 2007, 04:38:00 pm
EDIT: And what side project? Oh yeah if you could think of some great ideas for libraries I would consider
Another EDIT: DoorCS may support MirageOS but that is why it is more than a 1 page APP. If your thinking of including MOS libraries you are going to have to make it a 2 or 3 page APP and BE users don't want that. Also it includes rudementary things like multiplying and stuff. If any person is going to program for NexGenGS they need to be familiar with graphics programming and advanced topics so they should already be able to remake every MOS library so there is no need for them.
Post by: bfr on February 25, 2007, 04:40:00 pm
EDIT: The side project would be me helping with the routines
Post by: Halifax on February 25, 2007, 04:42:00 pm
EDIT: I also have input routines, and grayscale routines based off of RGP.
Post by: bfr on February 25, 2007, 05:04:00 pm
What's left? Color? :P
Post by: Halifax on February 25, 2007, 05:07:00 pm
Post by: bfr on February 25, 2007, 05:10:00 pm
Input routines? What kind?
Post by: Halifax on February 25, 2007, 05:13:00 pm
Post by: Jon on February 25, 2007, 05:33:00 pm
Post by: Halifax on February 25, 2007, 05:34:00 pm
Post by: Jon on February 25, 2007, 05:53:00 pm
On a lighter note, I have a key input routine that actually works (unlike the first one I made)
(note that lowercase_ofs has to be equated somewhere)
c1-->
| CODE |
| ec1 keyinput: vkinplp: push hl bcall(_getcsc) pop hl or a jr z,vkinplp cp skEnter jr z,vdoneinput cp skdel jr z,del_let cp skalpha jr z,tog_lower ld ix,chartable ld e,a ld d,0 add ix,de ld a,(ix) cp $ff jr z,vkinplp ld c,a ld a,(lowercase_ofs) add a,c ld (hl),a bcall(_putc) inc hl djnz vkinplp vdoneinput: xor a ld (lowercase_ofs),a ld (hl),0 ret del_let: push hl ld hl,curcol dec (hl) ld a,' ' bcall(_putmap) inc b pop hl dec hl jr vkinplp tog_lower: ld a,(lowercase_ofs) xor $20 ld (lowercase_ofs),a jr vkinplp CharTable: .db 0 .db $ff,$ff,$ff,$ff,$ff,$ff,$ff,$ff,$ff,$ff,"WRMH",$ff,$ff,"?",$ff .db "VQLG",$ff,$ff,":ZUPKFC",$ff," YTOJEB",$ff,$ff .db "XSNIDA",$ff,$ff,$ff,$ff,$ff,$ff,$ff,$ff,$ff c2 |
ec2
Post by: Halifax on February 25, 2007, 05:53:00 pm
Post by: Delnar_Ersike on February 25, 2007, 06:07:00 pm
Halifax, your shell's catch phrase should be "One shell to rule them all, one shell to find them. One shell to bring them all, and in the darkness, bind them." :Pthough I think that the two uber things you should add if there is room after 3D is sound and...MOS support.
As for the *possibly* best game ever for TI is made for Ion...
http://www.ticalc.org/archives/files/fileinfo/347/34799.html
http://www.ticalc.org/archives/files/fileinfo/348/34879.html
Post by: Jon on February 25, 2007, 06:09:00 pm
Delnar: it's not whether or not they are made for MirageOS, it's whether or not they use the MirageOS libraries, and since TVF also works on Ion as well, my guess is that it only uses Ion libraries. I can't be sure about Desolate, you would have to ask Tr1p1ea
Post by: trevmeister66 on February 25, 2007, 06:50:00 pm
)
Post by: Liazon on February 26, 2007, 11:02:00 am
either way, the readme in the .zip of Desolate I dled awhile back said something about the Venus shell, which was just ION w/ different GUI iirc.
Post by: Halifax on February 26, 2007, 01:38:00 pm
@delnar: Your first objection is not really valid because TVF was made to run under Ion for 83 which I don't know why he would take the time to port it to 83 Plus and use MOS libraries and second tr1p1ea may have used MOS for Desolate but that was his first game and he admits he was a beginner when he made it and if you look at Maxcoderz 5 year aniversary which clearly uses a better grayscale engine and runs under Ion. So I think that proves my point about NexGenGS is not for the beginner programmer.
@Liazon: Yes Desolate runs on Venus on the 83
[offtopic] I finally tracked down one of the reasons that TI-Connect gives the Acces Denied Error and that is because if you try to send a .83p to your calc then it will trigger that error until you downgrade. Phew! that took me about 2 weeks to debug ever possible way to do it :)
[/offtopic]
Post by: Fallen Ghost on February 26, 2007, 02:28:00 pm
Post by: Halifax on February 26, 2007, 02:31:00 pm
Note: Anyone who contributes routines to NexGenGS will have their name placed in the readme and be given full credit.
It would be cool if someone came up with a masked routine that saves the background.
Update: I will be adding your putsprite10, putsprite16, and masked sprite routine to the library because they are freakin fast as I dont know what!!!!
Post by: Halifax on February 26, 2007, 03:27:00 pm
Class
{
WinStem, WinTopic, StartPosX, StartPosY, XOffset, YOffset, HeaderButtons, BackGroundColor
}
Basically WinStem adds it to a specific Child/Parent Class so if you defined WinStem as Desktop then it would be considered part of the desktop and destroyed when the Desktop is. If you defined a Window with WinStem desktop and then another window with the stem of the first window then when that window with WinStem as Desktop is destroyed then the second one is too. Basically like a tree. WinTopic is the header title and all the other stuff is self explanatory.
So what other GUI stuff do you guys want??
Post by: Fallen Ghost on February 26, 2007, 04:10:00 pm
A not-too heavy GUI, exactly the contrary of what Kerm did for DCS 6 RC 1. Just a smooth thing, like Mirage, with functionnalities, but not superfluous functionnalities like a text-writer or some strange things no-one ever uses. It doesn't need to be beautiful. It needs to be workin great and giving ASM prog's a help with routines!
Post by: bfr on February 26, 2007, 04:30:00 pm
Post by: Jon on February 26, 2007, 04:33:00 pm
| QUOTE |
| It would be cool if someone came up with a masked routine that saves the background. |
Erm, didn't I already do that?
Post by: tifreak on February 27, 2007, 02:23:00 am
| QUOTE (Fallen Ghost @ 27 Feb, 2007, 3:10) |
| The next paragraph is only my thoughts, I cannot speak for others. A not-too heavy GUI, exactly the contrary of what Kerm did for DCS 6 RC 1. Just a smooth thing, like Mirage, with functionnalities, but not superfluous functionnalities like a text-writer or some strange things no-one ever uses. It doesn't need to be beautiful. It needs to be workin great and giving ASM prog's a help with routines! |
You do realize that those things are available for programmers as well, and elfprince was using them when he was making strategic conquest? I am sure once DCS is totally done, and adventurous asm programmers see what they can be used for, that it will become more popular...
If you make it shell like, make it like ion. Simple, and clean.
Post by: Halifax on February 27, 2007, 01:24:00 pm
@everyone else: Ok yes I agree I don't want a heavy GUI but my GUI will use a mouse but then the rest will be simple and clean. Thanks for the input. But one thing is I don't want the GUI to be like Ion or MOS or DoorCS. I want it to be different not just menus. So what I was thinking of doing is meshing the Ion type GUI with a mouse and directories and things. How's that sound.
Another update: I am thinking of adding multitasking and making an onboard contributation of 600 bytes towards it which would allow for two processes and two threads for each of those processer.( or four I forget)It would be able to be turned off by programmers who do not want it. But for programmers that do want it then it would provide a great aspect to programming. Any thoughts on that?
Major Update: I have been contemplating this and have decided I will include MOS libs as long as the app stays one page. One thing first anyone know where to find the source for them. I have looked almost everywhere and tried google.
Post by: Delnar_Ersike on February 27, 2007, 03:38:00 pm
| QUOTE |
| Another update: I am thinking of adding multitasking and making an onboard contributation of 600 bytes towards it which would allow for two processes and two threads for each of those processer.( or four I forget)It would be able to be turned off by programmers who do not want it. But for programmers that do want it then it would provide a great aspect to programming. Any thoughts on that? |
Great! Now programmers that are planning to put sound into their games can easily run the music and the game at once! :king:
Post by: Halifax on February 27, 2007, 03:44:00 pm
Post by: trevmeister66 on February 27, 2007, 03:53:00 pm
Post by: Halifax on February 27, 2007, 03:56:00 pm
NOTE: If I do make multitasking part of the shell then the shell will take 1 process and 1 thread to run. :/
Post by: Jon on February 27, 2007, 04:00:00 pm
Post by: Halifax on February 27, 2007, 04:03:00 pm
Post by: bfr on February 27, 2007, 05:20:00 pm
A mouse? That's probably going to complicate program selection and will probably result in the GUI being heavy.
EDIT: Also, if it uses a mouse, then programs won't be selected like how Flash Applications are selected on the TI-89 Titanium/Voyage 200, which you said you would do, right? You don't have to do it that way, but I'm just informing you....
Post by: Halifax on March 01, 2007, 12:58:00 pm
Post by: Jon on March 01, 2007, 02:21:00 pm
Post by: Halifax on March 02, 2007, 07:48:00 am
Post by: Fallen Ghost on March 02, 2007, 08:20:00 am
Using interrupts can be of great use, but if using interrupts for greyscale, then you're pretty much lost. Maybe like a counter or a call routine that preserves all registers? inserted in the program loop at certain intervals, like inside a GetKey call.
Post by: Halifax on March 02, 2007, 02:02:00 pm
Well I will just forget multitasking then
Post by: Fallen Ghost on March 02, 2007, 02:08:00 pm
c1-->
| CODE | ||||||||||||||||
| ec1 GetCSC: Post by: Jon on March 02, 2007, 04:15:00 pm c1-->
|
. Anyways, here it is.
