Jump to content


Dave-ee Jones

Member Since 19 Jan 2013
Offline Last Active Today, 05:13 AM
-----

Posts I've Made

In Topic: Copy a region of the screen?

Today, 05:12 AM

You could split your screen into segments with windows (buffers), however drawing to them would be quite difficult as you would need to calculate where your GUI needs to be laid out over all of them at once.

Think of 4 monitors stacked in a square, with Windows (the OS this time) desktop over all of them at once. You could save a part of a screen, but only the screen of one of the monitors. So you'd be saving a quarter of the whole desktop.

But at least you could copy the screen's contents, turn the screen off, turn it back on again, draw something to it separately etc. etc.

However, easiest way to go is just separating objects on your screen as buffers (as Bomb Bloke has said). The way I said is probably the most complicated it can get, and is still limited to saving a screen at a time.

In Topic: Program help

Yesterday, 11:03 PM

View PostSaldor010, on 06 January 2018 - 10:29 AM, said:

Arguably, Lua is easier to write in than C++ is..

View PostPurple, on 06 January 2018 - 12:53 PM, said:

LUA is definitively not easier to write than C++...

View PostSquidDev, on 06 January 2018 - 05:36 PM, said:

There are many ways you can describe C++, but "roughly as hard as Lua" is not one I'd use. C++ seems to revel in making things as hard as possible, and that's without talking about memory management.

View PostPurple, on 06 January 2018 - 12:53 PM, said:

programmer coming from actual programming
Ooooh, that hurt. Whilst Lua is used a lot as an embedded scripting language, I don't think it's fair to exclude from the ranks of "actual programming". There's a list of projects using it here, as well as companies which depend on it enough to invest money in its continued development.

He did say arguably, guys. Calm down.

In Topic: Best OS

08 December 2017 - 12:08 AM

Windows 7 (specifically, Pro x64 SP1).

It's the easiest to work with, easiest to modify and change, doesn't blurt out ads at you every 10 seconds, doesn't track you, doesn't cry about everything and is compatible with most software these days.

ComputerCraft-wise would probably be OneOS or djOS (though I never finished djOS so has to be OneOS). OneOS was quite polished and nice. :)

In Topic: Monitor touch interrupt

08 December 2017 - 12:04 AM

View PostLuca_S, on 07 December 2017 - 06:15 AM, said:

That would be a terrible idea to be honest.
Imagine a program with a GUI you can click in using sleep, if it captures the mouse_click events during the sleep a user might click randomly in the GUI to check if the program is hanging. All these clicks will then be used by the program and some strange stuff might happen.
If you really wanted to you could override the sleep function:

I thought that too at first, but then realised that it would only store the event queue it had BEFORE it started pulling them, not DURING or AFTER.

In Topic: Monitor touch interrupt

07 December 2017 - 05:17 AM

View PostKingofGamesYami, on 07 December 2017 - 12:30 AM, said:

If you call os.pullEvent without a parameter, it will return any event.

Example:

while true do
  local tEvent = {os.pullEvent()}
  print( "An event of type " .. tEvent[ 1 ] .. " has occurred" )
end

Assuming you are currently using sleep to update the monitor, it may be useful to view the actual declaration of sleep

Well, isn't that frustrating?
Calling sleep() clears your events because it's going through all those events!
It would be useful if you stored those events in a table and then queued them all again after the sleep() function has completed. Might not work well for longer sleep times but I haven't tested it.