Forums

Alright Zoop. You wanna see a tetris clone? I'll give you a tetris clone. You're doubting my skills? Talking down to me like I'm on another level? Don't forget that you have to take a shit just like I do every now and again.

Chris :o|

Quote

> Alright Zoop. You wanna see a tetris clone? I'll give you a tetris clone. You're doubting my skills? Talking down to me like I'm on another level? Don't forget that you have to take a shit just like I do every now and again.

I'm not doubting anyone skills. I'm quite sure that I would learn by making a tetris clone myself.
Good luck.
(and please keep this forum nice. i'm sorry if i did offend you or anything)

Quote

> I'm not doubting anyone skills. I'm quite sure that I would learn by making a tetris clone myself.
> Good luck.
> (and please keep this forum nice. i'm sorry if i did offend you or anything)

Well, this Tetris stuff is tough. I don't even know where
to begin. My approach was to create a memory table of
the area (10x20). My problem is rotating the blocks and
stuff. Tetris boggles the mind. Couldn't I do something
simpler like worms (game where you are a worm and as
you eat stuff you get larger) or Klax? I got an idea!!
Klax! Come on? Can I do Klax? Please!? Anything else
but Tetris.

Chris :o)

Quote

> Well, this Tetris stuff is tough.

Heh, you see now?

Quote

> I don't even know where to begin. My approach was to create a memory table of
> the area (10x20). My problem is rotating the blocks and stuff. Tetris boggles the
> mind. Couldn't I do something simpler like worms (game where you are a worm
> and as you eat stuff you get larger) or Klax? I got an idea!! Klax! Come on?
> Can I do Klax? Please!? Anything else but Tetris.

Sure you can do anything, you are doing it for you anyway :)

Quote

> Well, this Tetris stuff is tough. I don't even know where
> to begin. My approach was to create a memory table of
> the area (10x20). My problem is rotating the blocks and
> stuff. Tetris boggles the mind. Couldn't I do something
> simpler like worms (game where you are a worm and as
> you eat stuff you get larger) or Klax? I got an idea!!
> Klax! Come on? Can I do Klax? Please!? Anything else
> but Tetris.

Okay, how about Super Mario Bros.?

Come on, man, Tetris is about as easy as it gets. You don't need AI, you don't need sprites, you don't need collision detection (sort of but not really), or scrolling, or even need to handle multiple moving objects.

Don't make me cough up some code just to smack some humble into you.

That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :)

Quote

> Well, this Tetris stuff is tough. I don't even know where
> to begin. My approach was to create a memory table of
> the area (10x20). My problem is rotating the blocks and
> stuff. Tetris boggles the mind. Couldn't I do something
> simpler like worms (game where you are a worm and as
> you eat stuff you get larger) or Klax? I got an idea!!
> Klax! Come on? Can I do Klax? Please!? Anything else
> but Tetris.

The trick to any successful programming project is determining what data structures to use. After that, the algorithm falls into place.

Try an object-oriented approach. Consider each tetris piece as it's own object that "knows" how to rotate itself and to move itself. Consider the playing grid as an object that "asks" each piece to rotate or move depending on input from the user. The piece only needs to return information about the positions of each of the four blocks that make up the piece to the grid, so the display can be updated. The grid doesn't "care" about the type of piece, only the four positions of the blocks that make it up. At first, you can get away with only implementing a few pieces (like the straight or "L" pieces) until things are working smoothly, then implement more piece types later as you wish.

I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems.

Good luck.

Eric Quinn

Quote

> The trick to any successful programming project is determining what data structures to use. After that, the algorithm falls into place.

That's only half the trick. The other half is writing the code so that you can change it to do something else after six months of not looking at the source.

But yes, once you hold the data structures hostage the algorithms can be forced to do what you want. ^_^

Quote

> Try an object-oriented approach. Consider each tetris piece as it's own object that "knows" how to rotate itself and to move itself. Consider the playing grid as an object that "asks" each piece to rotate or move depending on input from the user. The piece only needs to return information about the positions of each of the four blocks that make up the piece to the grid, so the display can be updated. The grid doesn't "care" about the type of piece, only the four positions of the blocks that make it up. At first, you can get away with only implementing a few pieces (like the straight or "L" pieces) until things are working smoothly, then implement more piece types later as you wish.

Funny, I would have gone with a more procedural approac. To wit:

Have a 4x4 array for each piece, and declare one of the points as the "middle" (axis of rotation).
Then all you really have to worry about is collision detection, which can be implemented by "moving" the piece and seeing if any ot the blocks in the piece intersect anything already in the world (maximum compares: 16).
If it didn't collide, then the movement succeded. Otherwise, any rotation or left/right movement just doesn't work, and a downward movement copies the blocks of the piece into the world.
This only requires one array for the world, and N arrays (7?), one for each piece (actually, N*4 arrays, because you want one array for each orientation).
Also, this only requires one collision detection routine, doesn't need much thought to understand, etc. If anyone can think of a simpler approach, let me know.

I'd almost rather do tetris than Klax. Klax scoring has to be annoying.

Quote

> I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems.

And how many software projects end in failure? Some obscenely high number, I forget what.

If we were to design this as a OO project, what objects would you write?
For the subset of the problem discussed here, I see a "piece" and a "board".
Neither of them need subclasses, and if you aren't required by law to have
a superclass (Objective C, Smalltalk, etc.), then they don't need
one of those, either.

Quote

> Good luck.

Seconded. Good luck and Happy Coding. ^_^

Quote

> Eric Quinn

--Nyef

Quote

> That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :)

Hell, they could do it nine.
Eight? Naw, that's preposterous.

It occurs to me we're not talking about coding an SMS tetris.
That might be more interesting..but unneccesary I guess.

Quote

> > That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :)

> Hell, they could do it nine.
> Eight? Naw, that's preposterous.

After doing some research, I found an X tetris game that looks to be 4 lines long. I can't tell for sure, though, since my browser is acting funny.

Quote

> It occurs to me we're not talking about coding an SMS tetris.
> That might be more interesting..but unneccesary I guess.

Well, we aren't talking about creating an SMS tetris, but we aren't really _not_ talking about it, either.

In fact, this is the first mention of a target platform in this thread. ^_^

All those in favor of an SG-1000 tetris? ^_^

Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching).

--Nyef

A 4 line X tetris?

Quote

> Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching).

Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^

--Nyef

I am very interested too.
I feel we could do it nicely enough to have a separate main-purpose library done which will be re-usable.

Quote

> Funny, I would have gone with a more procedural approac. To wit:

> Have a 4x4 array for each piece, and declare one of the points as the "middle" (axis of rotation).
> Then all you really have to worry about is collision detection, which can be implemented by "moving" the piece and seeing if any ot the blocks in the piece intersect anything already in the world (maximum compares: 16).
> If it didn't collide, then the movement succeded. Otherwise, any rotation or left/right movement just doesn't work, and a downward movement copies the blocks of the piece into the world.
> This only requires one array for the world, and N arrays (7?), one for each piece (actually, N*4 arrays, because you want one array for each orientation).
> Also, this only requires one collision detection routine, doesn't need much thought to understand, etc. If anyone can think of a simpler approach, let me know.

Rather than using a whole array, I'd just have 4 pairs of x-y offsets from the center, since all tetris pieces are composed of four blocks.
As suggested above, I'd share a collision detection routine for the falling, rotating, and left/right detections. If during a rotation or left-right shift the detection routine reports a collision, then the move is rejected. If it reports a collision during a fall, then the pieces are copied into the world array... if any pieces are copied off of the puzzle, then ->BOOM<-, game over. Otherwise, the line scanner is run (that's pretty simple). Filled lines are removed, the puzzle is compacted (a little trickier, but just a simple memcpy/memclr or equivelant for loops would suffice), points are awarded, and the game continues.

The matter of rotation is slightly trickier...I'd probably just want to use a universal 'translation' function that accepts the x-y coordinates of the center piece, a rotation value (probably just 0 to 3 corresponding to 0, 90, 180, and 270 degrees), a pointer to the 'reference' piece definiation struct (the four pairs of x-y offsets), and a pointer to a scratch definition struct. The function would fill the scratch struct with the puzzle coordinates of each block in the shape.

To do the rotation:
0 Degrees: NewX = OldX, NewY = OldY;
90 Degrees: NewX = -OldY, NewY = OldX;
180 Degrees: NewX = -OldX, NewY = -OldY;
270 Degrees: NewX = OldY, NewY = -OldX;

To do the translation, just add the location of the center piece to each coordinate pair.

This routine could be shared by the collision scanner and the routine that actually draws the falling shape into place.

Quote

> I'd almost rather do tetris than Klax. Klax scoring has to be annoying.

> > I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems.

> And how many software projects end in failure? Some obscenely high number, I forget what.

depends how you classify failure. Is the project half-finished, or half-incomplete?

Quote

> If we were to design this as a OO project, what objects would you write?
> For the subset of the problem discussed here, I see a "piece" and a "board".
> Neither of them need subclasses, and if you aren't required by law to have
> a superclass (Objective C, Smalltalk, etc.), then they don't need
> one of those, either.

Tetris is just one of those oddly simple game ideas that just doesn't much need an OO approach: There's no change in the number of objects, or their type, or anything. Just a falling block routine with helper functions.

Quote

> > Good luck.

> Seconded. Good luck and Happy Coding. ^_^

And quit saying we don't help you!

Quote

> > Eric Quinn

> --Nyef

-And Me, Heliophobe

Quote

> > Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching).

> Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^

Um... PC Engine? That's exotic.. I guess the 6502 derivative it uses (ah, Hu6280 or somethin?) has a different entry address than the Z80...
If the NES's 6502 starts at the same address as the Hu6280, we could invent a detection routine to distinguish them.. and maybe add 7800 detection, and...

ah, so what else can we add to this 'meta-cartridge'? Gameboy on the Z80 code... I can't think of any more 8-bit systems...
But then, who said we had to stick with 8-bit?

What a delicious waste of time!

Quote

> --Nyef

Quote

> The matter of rotation is slightly trickier...I'd probably just want to use a universal 'translation' function that accepts the x-y coordinates of the center piece, a rotation value (probably just 0 to 3 corresponding to 0, 90, 180, and 270 degrees), a pointer to the 'reference' piece definiation struct (the four pairs of x-y offsets), and a pointer to a scratch definition struct. The function would fill the scratch struct with the puzzle coordinates of each block in the shape.

Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and.

Quote

> > And how many software projects end in failure? Some obscenely high number, I forget what.

> depends how you classify failure. Is the project half-finished, or half-incomplete?

That's the big question, isn't it?

If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it...

Quote

> Tetris is just one of those oddly simple game ideas that just doesn't much need an OO approach: There's no change in the number of objects, or their type, or anything. Just a falling block routine with helper functions.

True enough. And remember, OO is just a tool (for the sake of argument, we'll say it's a hammer). And like any Hammer, it also works on screws. ^_^

I actually have seen an OO tetris implementation before. At least, I think I have.

--Nyef

Quote

> > > Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching).

> > Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^

> Um... PC Engine? That's exotic.. I guess the 6502 derivative it uses (ah, Hu6280 or somethin?) has a different entry address than the Z80...

Indeed. It uses the same entry point as the NES.

Quote

> If the NES's 6502 starts at the same address as the Hu6280, we could invent a detection routine to distinguish them.. and maybe add 7800 detection, and...

Nope. The constraints of the .NES file format prevent that. Unless 0x4e 0x45 0x53 0x1e are a JMP to somewhere in the valid ROM area on an SMS?

Quote

> ah, so what else can we add to this 'meta-cartridge'? Gameboy on the Z80 code... I can't think of any more 8-bit systems...

The Gameboy header would conflict with the NES header. Don't forget the ColecoVision (which has it's own header that conflicts with the NES, and won't work on the SMS or GB unless 0x55 0xaa or 0xaa 0x55 are another valid jump...)

Quote

> But then, who said we had to stick with 8-bit?

Nobody. The SNES is doable, I think. The Genesis might be as well, but the first instruction of the SMS/SG-1000 part would also be a pointer to the first instruction of the Genesis code.

Quote

> What a delicious waste of time!

Indeed.

--Nyef

Quote

> The Gameboy header would conflict with the NES header. Don't forget the ColecoVision (which has it's own header that conflicts with the NES, and won't work on the SMS or GB unless 0x55 0xaa or 0xaa 0x55 are another valid jump...)

Oh, wait. I don't think it does. I think it conflicts with the Genesis header instead (oops).

--Nyef

Quote

> Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and.

Well now we're being SMS specific, I was thinking of a computer implementation.
But, yeah, either way, pre-rotated shape definitions definately make sense. I guess if you want to create new shapes, a rotating routine would make it less work to keep up.(or you could use macros which create rotation tables at compile time.. oh hell, this is getting silly.

Quote

> > depends how you classify failure. Is the project half-finished, or half-incomplete?

> That's the big question, isn't it?

> If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it...

So what was it originally supposed to do?

Thanks! Thank you all! *sniff* I begun to think no one
but Zoop and Eric cared. I see now :o)

Anyway, while you all were posting tons of messages on
my one message from last night, I was drawing figures
and thinking of techniques to rotate memory and I
figured it out. It a bit harder to do in Qbasic but
I was able to pull it off. The technique I used
is simple:

1) Get the length and width of the array
2) Allocate a dummy array for the rotation
***If you are rotating 90 Degrees (right)...
2a)Scan the memory from left to right and copy
from the height back to 0 to an offset variable.
With each verticle line that you copy, you send
the bytes to the variable and then you send the
variable to your dummy array. Once each Vline
has been scanned and transfered to the dummy
array, delete the original array and copy from
the dummy array to the merged array.
***If you are rotating -90 Degrees (left)...
2b)Do everything in reverse and the image or array
will be rotated.

Zoop, I'm sorry I got mad. I feel so proud! And what's
so cool is that I can use this technique for anything!
Say I decide to make an SMS Art program or something I've
harnesed this valuable technique. Thank you and thank
you everyone.

Chris :o)

Quote

> Thanks! Thank you all! *sniff* I begun to think no one
> but Zoop and Eric cared. I see now :o)

> Anyway, while you all were posting tons of messages on
> my one message from last night, I was drawing figures
> and thinking of techniques to rotate memory and I
> figured it out. It a bit harder to do in Qbasic but
> I was able to pull it off. The technique I used
> is simple:

> 1) Get the length and width of the array
> 2) Allocate a dummy array for the rotation
> ***If you are rotating 90 Degrees (right)...
> 2a)Scan the memory from left to right and copy
> from the height back to 0 to an offset variable.
> With each verticle line that you copy, you send
> the bytes to the variable and then you send the
> variable to your dummy array. Once each Vline
> has been scanned and transfered to the dummy
> array, delete the original array and copy from
> the dummy array to the merged array.
> ***If you are rotating -90 Degrees (left)...
> 2b)Do everything in reverse and the image or array
> will be rotated.

Yep, that works. We came up with some alternatives (prerotating the arrays for one) but the actualy technique is unimportant in light of the fact that it's just tetris, dammit.

Quote

>
> Zoop, I'm sorry I got mad. I feel so proud! And what's
> so cool is that I can use this technique for anything!

Yep, that's the thing. The best thing is to just try it, experiment, and maybe just fuck around into you've got something that works.

Quote

> > Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and.

> Well now we're being SMS specific, I was thinking of a computer implementation.

Actually, no. The .code segment is read-only in most computer implementations. Either approach is workable for either platform, the question is "which is easier to implement on which?".

Quote

> But, yeah, either way, pre-rotated shape definitions definately make sense. I guess if you want to create new shapes, a rotating routine would make it less work to keep up.(or you could use macros which create rotation tables at compile time.. oh hell, this is getting silly.

Yeah, silly is one word for it. Who really cares? ^_^

Quote

> > If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it...

> So what was it originally supposed to do?

See the comment at the top of tool.c, you can't really miss it. I don't really regret writing all that code ony to have someone else do what I wrote it to do, since the code wasn't really "wasted"... Even though there's very little of the original structure left.

Thinking about it, the file header comments may actually be the only bits of code that actually survived the evolution from the original code. Even the ROM loader was rewritten at one point. ^_^

Let's see... The debugger is no more, the I/O handlers were originally written in ASM, as were the CPU cores.
The main loop has moved about a bit over the years.
The CPU interface was redesigned at one point (and needs another rewrite already).
The NES mappers have been rebuilt at least 3 times.
Ah! I know. The NES memory banking is unchanged. It still uses the original 4 pointers for bankswitching. ^_^
Oh, and some of the code to parse the .NES file header is the same. That's about it. Everything else has been rewritten at least once over the years, or is new since I decided to turn it into a proper NES emulator.

--Nyef

Author	Message
Chris Guest	Tetris Clone Posted: Wed Mar 08, 2000 7:41 pm
Chris Guest	Alright Zoop. You wanna see a tetris clone? I'll give you a tetris clone. You're doubting my skills? Talking down to me like I'm on another level? Don't forget that you have to take a shit just like I do every now and again. Chris :o\|

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Wed Mar 08, 2000 8:19 pm
	Quote > Alright Zoop. You wanna see a tetris clone? I'll give you a tetris clone. You're doubting my skills? Talking down to me like I'm on another level? Don't forget that you have to take a shit just like I do every now and again. I'm not doubting anyone skills. I'm quite sure that I would learn by making a tetris clone myself. Good luck. (and please keep this forum nice. i'm sorry if i did offend you or anything)

Chris Guest	Posted: Thu Mar 09, 2000 1:46 am
Chris Guest	Quote > I'm not doubting anyone skills. I'm quite sure that I would learn by making a tetris clone myself. > Good luck. > (and please keep this forum nice. i'm sorry if i did offend you or anything) Well, this Tetris stuff is tough. I don't even know where to begin. My approach was to create a memory table of the area (10x20). My problem is rotating the blocks and stuff. Tetris boggles the mind. Couldn't I do something simpler like worms (game where you are a worm and as you eat stuff you get larger) or Klax? I got an idea!! Klax! Come on? Can I do Klax? Please!? Anything else but Tetris. Chris :o)

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Thu Mar 09, 2000 6:33 am
	Quote > Well, this Tetris stuff is tough. Heh, you see now? Quote > I don't even know where to begin. My approach was to create a memory table of > the area (10x20). My problem is rotating the blocks and stuff. Tetris boggles the > mind. Couldn't I do something simpler like worms (game where you are a worm > and as you eat stuff you get larger) or Klax? I got an idea!! Klax! Come on? > Can I do Klax? Please!? Anything else but Tetris. Sure you can do anything, you are doing it for you anyway :)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Mar 09, 2000 4:02 pm
	Quote > Well, this Tetris stuff is tough. I don't even know where > to begin. My approach was to create a memory table of > the area (10x20). My problem is rotating the blocks and > stuff. Tetris boggles the mind. Couldn't I do something > simpler like worms (game where you are a worm and as > you eat stuff you get larger) or Klax? I got an idea!! > Klax! Come on? Can I do Klax? Please!? Anything else > but Tetris. Okay, how about Super Mario Bros.? Come on, man, Tetris is about as easy as it gets. You don't need AI, you don't need sprites, you don't need collision detection (sort of but not really), or scrolling, or even need to handle multiple moving objects. Don't make me cough up some code just to smack some humble into you.

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Posted: Thu Mar 09, 2000 5:14 pm
	That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :)

Eric Guest	Posted: Thu Mar 09, 2000 6:24 pm
Eric Guest	Quote > Well, this Tetris stuff is tough. I don't even know where > to begin. My approach was to create a memory table of > the area (10x20). My problem is rotating the blocks and > stuff. Tetris boggles the mind. Couldn't I do something > simpler like worms (game where you are a worm and as > you eat stuff you get larger) or Klax? I got an idea!! > Klax! Come on? Can I do Klax? Please!? Anything else > but Tetris. The trick to any successful programming project is determining what data structures to use. After that, the algorithm falls into place. Try an object-oriented approach. Consider each tetris piece as it's own object that "knows" how to rotate itself and to move itself. Consider the playing grid as an object that "asks" each piece to rotate or move depending on input from the user. The piece only needs to return information about the positions of each of the four blocks that make up the piece to the grid, so the display can be updated. The grid doesn't "care" about the type of piece, only the four positions of the blocks that make it up. At first, you can get away with only implementing a few pieces (like the straight or "L" pieces) until things are working smoothly, then implement more piece types later as you wish. I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems. Good luck. Eric Quinn

Nyef Guest	Posted: Thu Mar 09, 2000 6:52 pm
Nyef Guest	Quote > The trick to any successful programming project is determining what data structures to use. After that, the algorithm falls into place. That's only half the trick. The other half is writing the code so that you can change it to do something else after six months of not looking at the source. But yes, once you hold the data structures hostage the algorithms can be forced to do what you want. ^_^ Quote > Try an object-oriented approach. Consider each tetris piece as it's own object that "knows" how to rotate itself and to move itself. Consider the playing grid as an object that "asks" each piece to rotate or move depending on input from the user. The piece only needs to return information about the positions of each of the four blocks that make up the piece to the grid, so the display can be updated. The grid doesn't "care" about the type of piece, only the four positions of the blocks that make it up. At first, you can get away with only implementing a few pieces (like the straight or "L" pieces) until things are working smoothly, then implement more piece types later as you wish. Funny, I would have gone with a more procedural approac. To wit: Have a 4x4 array for each piece, and declare one of the points as the "middle" (axis of rotation). Then all you really have to worry about is collision detection, which can be implemented by "moving" the piece and seeing if any ot the blocks in the piece intersect anything already in the world (maximum compares: 16). If it didn't collide, then the movement succeded. Otherwise, any rotation or left/right movement just doesn't work, and a downward movement copies the blocks of the piece into the world. This only requires one array for the world, and N arrays (7?), one for each piece (actually, N*4 arrays, because you want one array for each orientation). Also, this only requires one collision detection routine, doesn't need much thought to understand, etc. If anyone can think of a simpler approach, let me know. I'd almost rather do tetris than Klax. Klax scoring has to be annoying. Quote > I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems. And how many software projects end in failure? Some obscenely high number, I forget what. If we were to design this as a OO project, what objects would you write? For the subset of the problem discussed here, I see a "piece" and a "board". Neither of them need subclasses, and if you aren't required by law to have a superclass (Objective C, Smalltalk, etc.), then they don't need one of those, either. Quote > Good luck. Seconded. Good luck and Happy Coding. ^_^ Quote > Eric Quinn --Nyef

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Mar 09, 2000 7:15 pm
	Quote > That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :) Hell, they could do it nine. Eight? Naw, that's preposterous. It occurs to me we're not talking about coding an SMS tetris. That might be more interesting..but unneccesary I guess.

Nyef Guest	Posted: Thu Mar 09, 2000 7:42 pm
Nyef Guest	Quote > > That remember me of something. Two years ago I saw a 10 lines C program which was a textmode tetris for unix. quite funny :) > Hell, they could do it nine. > Eight? Naw, that's preposterous. After doing some research, I found an X tetris game that looks to be 4 lines long. I can't tell for sure, though, since my browser is acting funny. Quote > It occurs to me we're not talking about coding an SMS tetris. > That might be more interesting..but unneccesary I guess. Well, we aren't talking about creating an SMS tetris, but we aren't really _not_ talking about it, either. In fact, this is the first mention of a target platform in this thread. ^_^ All those in favor of an SG-1000 tetris? ^_^ Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching). --Nyef A 4 line X tetris?

Nyef Guest	Posted: Thu Mar 09, 2000 7:45 pm
Nyef Guest	Quote > Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching). Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^ --Nyef

Zoop Joined: 24 Jun 1999 Posts: 1732 Location: Paris, France	Re: Tetris Clone for SG-1000/SMS Posted: Thu Mar 09, 2000 8:14 pm
	I am very interested too. I feel we could do it nicely enough to have a separate main-purpose library done which will be re-usable.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Mar 09, 2000 8:15 pm
	Quote > Funny, I would have gone with a more procedural approac. To wit: > Have a 4x4 array for each piece, and declare one of the points as the "middle" (axis of rotation). > Then all you really have to worry about is collision detection, which can be implemented by "moving" the piece and seeing if any ot the blocks in the piece intersect anything already in the world (maximum compares: 16). > If it didn't collide, then the movement succeded. Otherwise, any rotation or left/right movement just doesn't work, and a downward movement copies the blocks of the piece into the world. > This only requires one array for the world, and N arrays (7?), one for each piece (actually, N*4 arrays, because you want one array for each orientation). > Also, this only requires one collision detection routine, doesn't need much thought to understand, etc. If anyone can think of a simpler approach, let me know. Rather than using a whole array, I'd just have 4 pairs of x-y offsets from the center, since all tetris pieces are composed of four blocks. As suggested above, I'd share a collision detection routine for the falling, rotating, and left/right detections. If during a rotation or left-right shift the detection routine reports a collision, then the move is rejected. If it reports a collision during a fall, then the pieces are copied into the world array... if any pieces are copied off of the puzzle, then ->BOOM<-, game over. Otherwise, the line scanner is run (that's pretty simple). Filled lines are removed, the puzzle is compacted (a little trickier, but just a simple memcpy/memclr or equivelant for loops would suffice), points are awarded, and the game continues. The matter of rotation is slightly trickier...I'd probably just want to use a universal 'translation' function that accepts the x-y coordinates of the center piece, a rotation value (probably just 0 to 3 corresponding to 0, 90, 180, and 270 degrees), a pointer to the 'reference' piece definiation struct (the four pairs of x-y offsets), and a pointer to a scratch definition struct. The function would fill the scratch struct with the puzzle coordinates of each block in the shape. To do the rotation: 0 Degrees: NewX = OldX, NewY = OldY; 90 Degrees: NewX = -OldY, NewY = OldX; 180 Degrees: NewX = -OldX, NewY = -OldY; 270 Degrees: NewX = OldY, NewY = -OldX; To do the translation, just add the location of the center piece to each coordinate pair. This routine could be shared by the collision scanner and the routine that actually draws the falling shape into place. Quote > I'd almost rather do tetris than Klax. Klax scoring has to be annoying. > > I know there's a lot of details I'm skipping, but try breaking down the problem into manageable parts and solving each part separately (object-oriented design is great for this). This approach is called "Divide and Conquer", and is an often used technique to solve programming problems. > And how many software projects end in failure? Some obscenely high number, I forget what. depends how you classify failure. Is the project half-finished, or half-incomplete? Quote > If we were to design this as a OO project, what objects would you write? > For the subset of the problem discussed here, I see a "piece" and a "board". > Neither of them need subclasses, and if you aren't required by law to have > a superclass (Objective C, Smalltalk, etc.), then they don't need > one of those, either. Tetris is just one of those oddly simple game ideas that just doesn't much need an OO approach: There's no change in the number of objects, or their type, or anything. Just a falling block routine with helper functions. Quote > > Good luck. > Seconded. Good luck and Happy Coding. ^_^ And quit saying we don't help you! Quote > > Eric Quinn > --Nyef -And Me, Heliophobe

mrscreen@hotmail.com Guest	Posted: Thu Mar 09, 2000 8:24 pm
mrscreen@hotmail.com Guest	Quote > > Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching). > Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^ Um... PC Engine? That's exotic.. I guess the 6502 derivative it uses (ah, Hu6280 or somethin?) has a different entry address than the Z80... If the NES's 6502 starts at the same address as the Hu6280, we could invent a detection routine to distinguish them.. and maybe add 7800 detection, and... ah, so what else can we add to this 'meta-cartridge'? Gameboy on the Z80 code... I can't think of any more 8-bit systems... But then, who said we had to stick with 8-bit? What a delicious waste of time! Quote > --Nyef

Nyef Guest	Posted: Thu Mar 09, 2000 8:33 pm
Nyef Guest	Quote > The matter of rotation is slightly trickier...I'd probably just want to use a universal 'translation' function that accepts the x-y coordinates of the center piece, a rotation value (probably just 0 to 3 corresponding to 0, 90, 180, and 270 degrees), a pointer to the 'reference' piece definiation struct (the four pairs of x-y offsets), and a pointer to a scratch definition struct. The function would fill the scratch struct with the puzzle coordinates of each block in the shape. Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and. Quote > > And how many software projects end in failure? Some obscenely high number, I forget what. > depends how you classify failure. Is the project half-finished, or half-incomplete? That's the big question, isn't it? If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it... Quote > Tetris is just one of those oddly simple game ideas that just doesn't much need an OO approach: There's no change in the number of objects, or their type, or anything. Just a falling block routine with helper functions. True enough. And remember, OO is just a tool (for the sake of argument, we'll say it's a hammer). And like any Hammer, it also works on screws. ^_^ I actually have seen an OO tetris implementation before. At least, I think I have. --Nyef

Nyef Guest	Posted: Thu Mar 09, 2000 8:40 pm
Nyef Guest	Quote > > > Hell, we could have some real fun, and make the same ROM work on both the SG1000 and the SMS. I think I know how to tell which one you're running on at runtime (hint: bankswitching). > > Ooh. Evil thought. And the PC-Engine/TurboGrafx-16. It would require writing twice the code, but it could be done. And if we use BG images for the more advanced (SMS/PCE) systens, they should work on both. ^_^ > Um... PC Engine? That's exotic.. I guess the 6502 derivative it uses (ah, Hu6280 or somethin?) has a different entry address than the Z80... Indeed. It uses the same entry point as the NES. Quote > If the NES's 6502 starts at the same address as the Hu6280, we could invent a detection routine to distinguish them.. and maybe add 7800 detection, and... Nope. The constraints of the .NES file format prevent that. Unless 0x4e 0x45 0x53 0x1e are a JMP to somewhere in the valid ROM area on an SMS? Quote > ah, so what else can we add to this 'meta-cartridge'? Gameboy on the Z80 code... I can't think of any more 8-bit systems... The Gameboy header would conflict with the NES header. Don't forget the ColecoVision (which has it's own header that conflicts with the NES, and won't work on the SMS or GB unless 0x55 0xaa or 0xaa 0x55 are another valid jump...) Quote > But then, who said we had to stick with 8-bit? Nobody. The SNES is doable, I think. The Genesis might be as well, but the first instruction of the SMS/SG-1000 part would also be a pointer to the first instruction of the Genesis code. Quote > What a delicious waste of time! Indeed. --Nyef

Nyef Guest	Posted: Thu Mar 09, 2000 8:43 pm
Nyef Guest	Quote > The Gameboy header would conflict with the NES header. Don't forget the ColecoVision (which has it's own header that conflicts with the NES, and won't work on the SMS or GB unless 0x55 0xaa or 0xaa 0x55 are another valid jump...) Oh, wait. I don't think it does. I think it conflicts with the Genesis header instead (oops). --Nyef

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Thu Mar 09, 2000 8:56 pm
	Quote > Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and. Well now we're being SMS specific, I was thinking of a computer implementation. But, yeah, either way, pre-rotated shape definitions definately make sense. I guess if you want to create new shapes, a rotating routine would make it less work to keep up.(or you could use macros which create rotation tables at compile time.. oh hell, this is getting silly. Quote > > depends how you classify failure. Is the project half-finished, or half-incomplete? > That's the big question, isn't it? > If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it... So what was it originally supposed to do?

Chris Guest	Yes! I can rotate the blocks! Posted: Thu Mar 09, 2000 9:36 pm
Chris Guest	Thanks! Thank you all! sniff I begun to think no one but Zoop and Eric cared. I see now :o) Anyway, while you all were posting tons of messages on my one message from last night, I was drawing figures and thinking of techniques to rotate memory and I figured it out. It a bit harder to do in Qbasic but I was able to pull it off. The technique I used is simple: 1) Get the length and width of the array 2) Allocate a dummy array for the rotation *If you are rotating 90 Degrees (right)... 2a)Scan the memory from left to right and copy from the height back to 0 to an offset variable. With each verticle line that you copy, you send the bytes to the variable and then you send the variable to your dummy array. Once each Vline has been scanned and transfered to the dummy array, delete the original array and copy from the dummy array to the merged array. *If you are rotating -90 Degrees (left)... 2b)Do everything in reverse and the image or array will be rotated. Zoop, I'm sorry I got mad. I feel so proud! And what's so cool is that I can use this technique for anything! Say I decide to make an SMS Art program or something I've harnesed this valuable technique. Thank you and thank you everyone. Chris :o)

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Yes! I can rotate the blocks! Posted: Thu Mar 09, 2000 11:10 pm
	Quote > Thanks! Thank you all! sniff I begun to think no one > but Zoop and Eric cared. I see now :o) > Anyway, while you all were posting tons of messages on > my one message from last night, I was drawing figures > and thinking of techniques to rotate memory and I > figured it out. It a bit harder to do in Qbasic but > I was able to pull it off. The technique I used > is simple: > 1) Get the length and width of the array > 2) Allocate a dummy array for the rotation > *If you are rotating 90 Degrees (right)... > 2a)Scan the memory from left to right and copy > from the height back to 0 to an offset variable. > With each verticle line that you copy, you send > the bytes to the variable and then you send the > variable to your dummy array. Once each Vline > has been scanned and transfered to the dummy > array, delete the original array and copy from > the dummy array to the merged array. > *If you are rotating -90 Degrees (left)... > 2b)Do everything in reverse and the image or array > will be rotated. Yep, that works. We came up with some alternatives (prerotating the arrays for one) but the actualy technique is unimportant in light of the fact that it's just tetris, dammit. Quote > > Zoop, I'm sorry I got mad. I feel so proud! And what's > so cool is that I can use this technique for anything! Yep, that's the thing. The best thing is to just try it, experiment, and maybe just fuck around into you've got something that works.

Nyef Guest	Posted: Fri Mar 10, 2000 2:27 pm
Nyef Guest	Quote > > Why not just store the co-ordinates in ROM, and have a separate set for each of 4 possible orientations? Rotation is then an inc/dec and an and. > Well now we're being SMS specific, I was thinking of a computer implementation. Actually, no. The .code segment is read-only in most computer implementations. Either approach is workable for either platform, the question is "which is easier to implement on which?". Quote > But, yeah, either way, pre-rotated shape definitions definately make sense. I guess if you want to create new shapes, a rotating routine would make it less work to keep up.(or you could use macros which create rotation tables at compile time.. oh hell, this is getting silly. Yeah, silly is one word for it. Who really cares? ^_^ Quote > > If you call a project that will never do what it was originally supposed to do a failure, then DarcNES is a failure. Is DarcNES a failure? Somehow I doubt it... > So what was it originally supposed to do? See the comment at the top of tool.c, you can't really miss it. I don't really regret writing all that code ony to have someone else do what I wrote it to do, since the code wasn't really "wasted"... Even though there's very little of the original structure left. Thinking about it, the file header comments may actually be the only bits of code that actually survived the evolution from the original code. Even the ROM loader was rewritten at one point. ^_^ Let's see... The debugger is no more, the I/O handlers were originally written in ASM, as were the CPU cores. The main loop has moved about a bit over the years. The CPU interface was redesigned at one point (and needs another rewrite already). The NES mappers have been rebuilt at least 3 times. Ah! I know. The NES memory banking is unchanged. It still uses the original 4 pointers for bankswitching. ^_^ Oh, and some of the code to parse the .NES file header is the same. That's about it. Everything else has been rewritten at least once over the years, or is new since I decided to turn it into a proper NES emulator. --Nyef

Forums

View topic - Tetris Clone