Jump to content




Gopher's APIs - Old, and broken, but still good. Yah. Still good.

api

83 replies to this topic

#81 GopherAtl

  • Members
  • 888 posts

Posted 14 March 2015 - 01:55 AM

:blows dust off thread:

redirect and ggui have both been updated to work in this world of of stackless term.redirect behavior. I think. The sample programs seem to work again, in any case. Report any further issues with those two here.

goroutines and ctrlkeys... I've moved away from. The former, I've just moved away from that style of coroutine-heavy programming in CC, and ctrlkeys, I have heard said, had some platform-specific flaws in it's basic approach, and did not work consistently across different operating systems. I'm leaving them up, for now, but they won't be updated and, indeed, I've not even tested to see if they still work or not, so use at your own risk. As before, all of these APIs are wtfpl, meaning you can do whatever you want with them. Wanna use a modified version in your OS? Feel free! Got someone willing to give you cash money in exchange for a compeltely unaltered copy? Go ahead, take that sucker's money. I honestly don't care! Just do wtf you want!

View PostSymmetryc, on 22 November 2013 - 11:03 PM, said:

Ctrl Keys seems a bit overly complex, couldn't you just do something like this?

local pullEvent = function(_filter)
	local t = {}
	while t[1] ~= (_filter or t[1] or 0) do
		t = {os.pullEvent()}
		t[1] = t[1] == "key" and (os.startTimer(0) == ({os.pullEvent()})[2] and "ctrl_key" or os.pullEvent() and t[1]) or t[1]
	end
	return unpack(t)
end

Or am I just missing something?

Edit: I've updated the code, but I can see that it has some problems; You can't pull events more than about 6 or 7 times a second, otherwise it may mistake ctrl_keys as normal keys :/.

yes. Yes, it could be much simpler. If I were writing it now, knowing all I've learned since then (ctrlkeys was one of my first apis posted on the forums), I would have made a version that didn't queue events or use timers at all.

Edited by GopherAtl, 14 March 2015 - 01:58 AM.


#82 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 14 March 2015 - 03:05 AM

No offense, but goroutines where pretty useless :P
Redirect, however, is, and still is, and absolutely brilliant and super efficient API.

#83 GopherAtl

  • Members
  • 888 posts

Posted 14 March 2015 - 03:29 AM

goroutines was slick. My old multishell used it to great effect. It was a bit buggy, though, I'll grant you.

#84 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 14 March 2015 - 03:59 PM

why not just use coroutines though?

edit:
I've found redirect buffers to be super laggy when active. They're great when you're going to blit(), but I'm probably going to go with a different buffer system for my OS. Game-engine will stay with redirect.
also: redrawing the screen every time there's a change...
...not the best idea.

I'm going to make a buffer system that will, instead of redrawing the screen, will also write directly to it when active.
Also, the write() function will be somewhat lazy-- it will do the absolute least math as possible, and save all calculaions for blit(). Meaning, it just tells the color of a pixel, and text is whatever you input--it doesn't do like [1] = "a" [2] = "b" [3] = "c", it does [1]="abc". And if you write to 2, the buffer becomes [1]="abc" [2] = "dc", but 2 has a higher operation number(a number that increases each time you write to the screen) and therefore is always done after 1.
Although, all x values are on a y table, I should have said the y table rather than the buffer.

Edited by Geforce Fan, 18 March 2015 - 02:01 AM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users