BBTetris

Bomb Bloke, on 09 November 2013 - 07:26 PM said:

Having to type a parameter to indicate you don't want to use a monitor is more effort then just tapping "n" when the program launches. Still, I suppose that's enough of an excuse to implement an INI file - now it'll generate one the first time you run it (BBTetris.ini), and if you open that up with your editor of choice the rest should be self explanatory.

Thanks for the feedback, folks! :)/>

Bomb Bloke, on 09 November 2013 - 08:40 PM said:

Unfortunately it tried to handle resizes that weren't happening to the monitor it had control over (as I found on testing your mirroring tool), so I've again tweaked the code a bit.

Symmetryc, on 10 November 2013 - 08:48 AM said:

There are a few things that you could've done to make your life easier, but very nice and solid program nonetheless :D/>

Xenthera, on 10 November 2013 - 06:03 PM said:

Not gonna lie. I spent a few hours playing it…

Bomb Bloke, on 16 November 2013 - 02:14 AM said:

Symmetryc, on 10 November 2013 - 08:48 AM said:

There are a few things that you could've done to make your life easier, but very nice and solid program nonetheless :D/>

I'm about at the point where I'm pretty sure this thing is "stable", but I'd still appreciate any tips on improving it (even if I might not use them until I write some other program). There's still a lot about Lua that I don't know. :)/>

[[
Hello!
Bye!
]]

-- old way
print("\nIf you wish to copy me to your internal drive (for play without the disk), type:\n\ncp \\disk\\BBTetris \\BBTetris\n")

-- new way
print([[
If you wish to copy me to your internal drive (for play without the disk), type:

cp \disk\BBTetris \BBTetris
]])

-- Note: Putting "\\" in multiline strings will simply give you "\\"; Characters won't be escaped.

Bomb Bloke, on 16 November 2013 - 06:39 PM said:

but I rather suspect that Lua's implementation wastes bucket loads of RAM duplicating functions to pull it off

Yevano, on 16 November 2013 - 06:57 PM said:

Bomb Bloke, on 16 November 2013 - 06:39 PM said:

but I rather suspect that Lua's implementation wastes bucket loads of RAM duplicating functions to pull it off

If you use metatables, you don't have to worry about that. The common thing to do is to create a class table to hold all your functions and set the metatable of all instances to that of the class. That way, they just call the class function, passing the object in as self.

error("No file or line numbers shown, just this message in red", 0)

theoriginalbit, on 17 November 2013 - 07:52 AM said:

I am curious as to why you're doing an else block with do block inside of it at 1213.

theoriginalbit, on 17 November 2013 - 07:52 AM said:

Also don't forget about the error level of 0.

error("No file or line numbers shown, just this message in red", 0)

Bomb Bloke, on 17 November 2013 - 05:58 PM said:

Just a quick way to have the "sides" table discarded when I was done with it.

Bomb Bloke, on 17 November 2013 - 05:58 PM said:

I think I'm not so much forgetting it as not knowing why I need it in the first place. :unsure:/>/>

If you're wondering about my use of the "erroring" value, that's less to report that "there was a problem at line such-and-such" and more to report things like "the user bulldozed my monitor!" - I then want it to go on to output the usual closing statements too. But I suspect that's not what you're getting at.

Bomb Bloke, on 16 November 2013 - 06:39 PM said:

I'm also a little suspicious as to how OOP works in Lua: I mean, there are times when that technique certainly seems to fit (eg, you've got a ton of enemies on screen which all have the same properties/functions), but I rather suspect that Lua's implementation wastes bucket loads of RAM duplicating functions to pull it off (er, or at least, more RAM then it usually does ;)/> ). No idea, I'll have to try defining some and find out what the options are, as it can improve readability if nothing else.

Thanks! :)/>

local max_x, max_y = term.getSize()
local blocks = {
	types = {
		{
			{0, 1, 0};
			{1, 1, 0};
			{0, 1, 0};
		};
		{
			{1, 0, 0};
			{1, 0, 0};
			{1, 1, 0};
		}
			-- etc.
	};
	new = function(self, _x, _y)
		return {
			x = _x or math.random(1, max_x - 2);
			y = _y or math.random(1, max_y - 2);
			type = self.blocks[math.random(1, #self.blocks)];
		}
	end;

	--update method (moves blocks by 1)

	--collision check method

	--etc.
}

local tScreenObjects = {}
local exit = function()
  error("Thank you for playing this game =D", 0)
end
-- use of button "class" (OOP), making it easy to create buttons and use of table
-- argument to enhance readability.
tScreenObjects.exitButton = button.new({x = 1, x2 = 5, y = 6, y2 = 7, func = exit, color = colors.red})

local event, x, y = os.pullEvent()
if event == "mouse_click" then
  -- Again, use of button "class"
  button.getButtonAt(tScreenObjects, x, y).func()
end

theoriginalbit, on 17 November 2013 - 06:45 PM said:

But its local to the else block, so it will be discarded when the else block is finished.

theoriginalbit, on 17 November 2013 - 06:45 PM said:

Yeh I'm more talking about lines 1246-1251

Symmetryc, on 17 November 2013 - 08:23 PM said:

One way to do OOP (or something resembling it) would be to do something like this (your implementation of blocks is probably way different, but you can probably get the idea of what I'm talking about):

Bomb Bloke, on 18 November 2013 - 07:09 AM said:

I got most of the way to work before realising that's what your answer would be… not 'cause I remembered that's how it worked so much as I figured out that you wouldn't ask if it didn't.

I have a memory of testing that out, but not a whit of memory as to what the result was. I must've shuffled that code in there later on thinking I knew what I was doing.

Bomb Bloke, on 18 November 2013 - 07:09 AM said:

… and while at work I probably spent too much of my time refreshing Pastebin so I could review those lines (it was "under heavy load" most of the day, apparently).

Anyway, yeah, that's a good spot for it. :)/>

Bomb Bloke, on 18 November 2013 - 07:09 AM said:

Symmetryc, on 17 November 2013 - 08:23 PM said:

One way to do OOP (or something resembling it) would be to do something like this (your implementation of blocks is probably way different, but you can probably get the idea of what I'm talking about):

That's actually near identical, yes - a table of the things with a few variables to keep track of which is in use, and where it is.

I do get how OOP would be implemented here (my worry re function duplication wouldn't've applied even if true, given that I only have one block on screen at a time), what I don't get is the "why" (… given that I only have one block on screen at a time). But thanks.

I suspect it boils down to what one's familiar with, or one's personal style. For example, I find the system of applying functions to button objects a right nuisance to read, because although it's very clear that there's a selection of buttons and the program is checking to see if any have been clicked, it becomes a royal nuisance to work out what they do - I'd rather have all that code in the one place then spread out at intervals throughout the source. It's like the difference between reading a regular book or a "choose your own adventure" novel to me, and when a function is only called from one specific place in the code then the whole thing seems like a waste of time.

Dunno.