Author Topic: NexGenGS (Read 16781 times)

Halifax · « **on:** February 25, 2007, 04:28:00 pm »

This is a game shell more than an OS. Hence the GS. This will be targetted towards the everyday ASM programmer who needs quick and optimized graphics routines and thinks that overall make everything easier.

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.

tifreak · « **Reply #1 on:** February 25, 2007, 04:32:00 pm »

Sounds like a good idea. You will need to make some example programs of what it can do...

Halifax · « **Reply #2 on:** February 25, 2007, 04:35:00 pm »

Yeah definetly tifreak8x. This will probaly be the most powerful library to-date.

bfr · « **Reply #3 on:** February 25, 2007, 04:36:00 pm »

Awesome! I already suggested this to you before, I think, but I think it would be cool if programs were selected and run just like how apps are on a Voyage 200/TI-89 Titaniun. Also, make sure that it is not only compatible with Ion, but MirageOS too.

*bfr

Halifax · « **Reply #4 on:** February 25, 2007, 04:38:00 pm »

Haha bfr read the first post and yes I have thought of your idea and I was going to implement it. Why make support for MOS. The *possibly* greatest program ever, Phoenix 3.3 runs on Ion.

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.

bfr · « **Reply #5 on:** February 25, 2007, 04:40:00 pm »

Right now, I have a really fast aligned sprite routine (which is probably faster than Ion's routine), and I could probably think of some more. Maybe a tile-mapping routine (which could be based off of the aligned sprite routine), but that might be overkill.

EDIT: The side project would be me helping with the routines

Halifax · « **Reply #6 on:** February 25, 2007, 04:42:00 pm »

Bfr I already having a smoothscrolling tilemap implemented into NexGenGS and an aligned sprite routine.

EDIT: I also have input routines, and grayscale routines based off of RGP.

bfr · « **Reply #7 on:** February 25, 2007, 05:04:00 pm »

Wow. o.o

What's left? Color?

Halifax · « **Reply #8 on:** February 25, 2007, 05:07:00 pm »

Yo thanks for the idea im going to implement that

bfr · « **Reply #9 on:** February 25, 2007, 05:10:00 pm »

3-D might also be overkill. If the application is small enough, though, then 3-D might not be such a bad idea.

Input routines? What kind?

Halifax · « **Reply #10 on:** February 25, 2007, 05:13:00 pm »

Input routines as in like letting the user type in a series of characters that are stored into a string. Other stuff like that for the graphscreen and the homescreen. And 3D wouldn't be overkill considering it doesn't take up that much space.

Jon · « **Reply #11 on:** February 25, 2007, 05:33:00 pm »

Jon looks up raycasting....

Halifax · « **Reply #12 on:** February 25, 2007, 05:34:00 pm »

Not that type of 3D dude. True-3D. I have done it in basic before.

Jon · « **Reply #13 on:** February 25, 2007, 05:53:00 pm »

* Jon shuts up

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

Halifax · « **Reply #14 on:** February 25, 2007, 05:53:00 pm »

kk cool thanks