Home | Reviews | GUIpedia | Forum | Fun500

agumaSpark v0.2
Spark 0.2 is going to have MULTITASKING! The thing I want to ask you guys is IS THERE A BETTER WAY THEN DOING FOR Prog = 1 to 20 ExecuteInstruction(Prog) NEXT Prog I've tried interrupts, but the problem is if one interrupt gets interrupted by another interrupt, the previous interrupt will be forgotten! I could use a stack, but it can overflow if the user keeps changing the active window. So what ideas do YOU have? ;)		2008-09-141:09 PM
ToddRe:Spark v0.2
You could try TSRs. I got one to work in QB but you have to know what you're doing. They typically can handle 2 programs but pushing it to 3 can wear it out. Maybe have the desktop as the first and the program running to be the second.		2008-09-141:28 PM
agumaRe:Spark v0.2
You mean Terminate and Stay-Resident? Then you'd have to make every program specially designed for it, which would be REALLY HARD...but thanks for the input anyway ;)		2008-09-141:32 PM
ksrRe:Spark v0.2
Specifically what do you not like about the code you posted, aguma?		2008-09-141:55 PM
agumaRe:Spark v0.2
Well, it's too slow.		2008-09-142:18 PM
ksrRe:Spark v0.2
Well, a FOR Prog = 1 to maxProgs type loop is probably the fastest way of doing things. Maybe your actual ExecuteInstruction procedure is too slow?		2008-09-143:51 PM
ToddRe:Spark v0.2
That's a possibility. The FOR will also ensure better multi-threading when running active programs at the same time. aguma, I don't know if it's any help but try having scripts run on the SIMPLEST language possible! Like let's say I wrote a script like this: [code] PRINT "Hello, what's your name?" INPUT "", name$ PRINT "Hello " + name$ [/code] and if I translated it into the simplest language possible, it would look like this: [code] ' 1 - enter data into buffer ' 2 - print data at index ' 3 - input data to temp_buf ' 4 - store data from temp_buf in buffer 1,Hello, what's your name? 1,Hello 2,1 3 4 2,2 2,3 [/code] "2,3" will print the input data stored in the buffer. When it was stored, it was indexed as #3 since the buffer indexes strings starting at 1. You could use 0, but BASIC tends to use 1 quite a lot.		2008-09-144:26 PM
agumaRe:Spark v0.2
Well I haven't started it yet, but I was just thinking about GIMI which takes like 5 hours to load everything!		2008-09-144:49 PM
ToddRe:Spark v0.2
Yeah but don't forget, GIMI had some small flaws. Like it would redraw the entire window every time it was dragged or it would redraw EVERYTHING when a new program was opened.		2008-09-144:51 PM
agumaRe:Spark v0.2
lol		2008-09-145:03 PM
BrandonRe:Spark v0.2
fun500 4= speed		2008-09-145:22 PM
SonicBritRe:Spark v0.2
Well this would depend on how the programs themselves get executed. Are they executed as part of a parsed script language or are they inside of basic itself? If its the first, you could easily use some kind of increment say after parsing so many lines or tokens flip to the next process, or you could use a specific keyword to release time to the kernel, VB uses doevents to release time back to VBs kernel as well as handling any queued up windows events. If its the second, you could also use the specific keyword, which would require you to write it into your programs at key points where its going to do looping or intensive operations. The other part is of course when it calls your kernel routines (windows, graphics etc..) at the end of your procedures have it call another routine that checks whether it should flip to another app. Once you decide on your method, you also need to decide how to keep track of which app currently has focus, how long they will have it for, and when you need to move to the next app, which one will have priority (if you use priorities), or you could just assume the next app in the queue needs processing. In many kernels there are ways to release time to the kernel (sleep for example), or ways to wait for events to happen, so that way the app isn't doing any useless processing.		2008-09-156:01 PM
Re:Spark v0.2
There is no such thing as speed in QBasic... LOL I was coding this window engine, and what happened was that whenever I would drag it or resize it, it would get all flickery... I speed up the draggin/resizing line to 60hz (WAIT statement) and what happened was it was still flickering because a simple PRINT statement slowed it all down! So I had to remove it...		2008-09-174:06 PM
Re:Spark v0.2
[b]aguma wrote:[/b] [quote]lol[/quote] What is so funny?		2008-09-1710:39 PM
ToddRe:Spark v0.2
He was laughing at my GIMI comment a few posts up.		2008-09-1711:19 PM
jasonwoodlandRe:Spark v0.2
I've seen slower that GIMI, this GUI felt like every time it looped there were 500 WAIT &H3DA, 8 commands shoved in.		2008-09-1812:26 AM
Re:Spark v0.2
Why exactly makes you think the WAIT command is what slowed it down?		2008-09-183:18 PM
jasonwoodlandRe:Spark v0.2
I was sorta saying it as a metaphor, idiom one of those. lol.		2008-09-185:56 PM
ToddRe:Spark v0.2
"WAIT &H3DA, 8" is supposed to indicate a vertical trace, I believe. I'd Google it and see what it means. It shouldn't slow it down. But if you take it out, try it and see how it works without it.		2008-09-186:09 PM
Re:Spark v0.2
wait &h3da, 8 wait &h3da,8,8 Yes that is what it does, I use it in 9OS. I wouldn't slow it down too much. It is better for performance as it reduces flickering by speeding up the monitor to 60hz. One thing I noticed about it is that when you have a slow statement in wait &h3da's loop, (such as PRINT) it will slow it down and make it flickery.		2008-09-186:46 PM
agumaRe:Spark v0.2
It's time...for another windowing demo! This one is really different-looking than some other ones I made, for example the title bar is...well, not there. I'm going to add textboxes next. I hope it works fast enough, it works really good in DOSBox 25000 cycles on Windows (on Linux it goes sorta slowly). Tell me if you have any problems or stuff! EDIT: lol...I...forgot to put the link! LOLOLOLOL anyway here it is http://uppit.com/2T8GOS Oops, you need the EXE since the BI isn't included :P Hm, it won't compile! I'll post it soon enough...		2008-09-187:37 PM

Blog

2021 Brandon Cornell