LongTris (WIP)

Tools and projects
Post Reply
User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

LongTris (WIP)

Post by blabla » Tue Sep 15, 2015 3:26 am

For now, this is going to be a development thread for LongTris, a tetris clone.

I'm going to make sure that LongTris is going to the definitive Tetris clone for 3DO.
I don't think a port of Tetris was done or even planned...

Image

Downloads:
Alpha 1

Github repo:
https://github.com/gameblabla/longtris-3do

Set Goals:
  • Improve performance & drawing Not done
    Add music & sound effects. Not done
    Add texts for score, highscore... Done
    Add a menu Not done
    Eventually save the highscore inside the 3DO's flash memory. Not done
Last edited by blabla on Fri Sep 18, 2015 1:38 pm, edited 2 times in total.

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Wed Sep 16, 2015 4:57 am

Haha! That was my plan for a while until I got swamped with school and other stuff. Maybe I'll still get around to making mine and we'll see whose is better!

I was going to build mine from scratch, though. We'll see exactly how that works out...

User avatar
T2KFreeker
3DO ZERO USER
Posts: 1241
Joined: Wed Feb 07, 2007 6:41 am
Location: Parts Unknown

Re: LongTris (WIP)

Post by T2KFreeker » Wed Sep 16, 2015 7:31 am

You know, I( would be down for some Tetris on the 3DO as long as the controls are nice. So many Tetris games I play that don't feel quite right. You get it feeling right though and this could be really bad ass. Good Luck to you both and let's get it done.
This is a stick up! Put all of your 3DO games in the bag and nobody gets hurt!

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Thu Sep 17, 2015 1:33 pm

So i was able to get a first version working properly,
a playable alpha is now available for download.

There's one big issue with it though :
When there are too much blokcs (about 1 third of the playfield), it will flicker.

3DO weren't kidding when they said that their pixels routines were too slow...
Err WritePixel (Item bitmapItem,GrafCon *gc,Coord x, Coord y)

Description
This call writes a pixel to the display of the specified bitmap. The pixel is rendered in the foreground color of the GrafCon structure. It is rendered on the column and row specified by the x and y arguments respectively.

Notes
The current implementation of this routine is very slow. This will change in future releases.

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Fri Sep 18, 2015 7:09 am

blabla wrote:So i was able to get a first version working properly,
a playable alpha is now available for download.

There's one big issue with it though :
When there are too much blokcs (about 1 third of the playfield), it will flicker.

3DO weren't kidding when they said that their pixels routines were too slow...
Err WritePixel (Item bitmapItem,GrafCon *gc,Coord x, Coord y)

Description
This call writes a pixel to the display of the specified bitmap. The pixel is rendered in the foreground color of the GrafCon structure. It is rendered on the column and row specified by the x and y arguments respectively.

Notes
The current implementation of this routine is very slow. This will change in future releases.
Yeah. I was wondering what you used to write a pixel. I saw that in documentation and shied away from using it. I was going to work on writing pixels to a CEL/bitmap, using it like a backbuffer, and then rendering that to the screen, although that might be what they are doing already. But if they were just doing that, then I don't see why it would be so slow... We'd just need to know the formatting, no?

For my Tetris, I was likely going to have my implementation use CELs drawn to the screen using the CEL engine. Since it runs on the GPU, it should lighten the load from drawing on a pixel-per-pixel basis. And I can rotate/skew them if I want!

I also really need to do some benchmarking. How many CPU calculations can we realistically do at 30fps? How many CELs (GPU) can we render before taking a hit? How many together, etc. And framerate counters and stuff. Then, I could test exactly how slow WritePixel() is compared to other methods and seeing if any of us could make anything faster at all.

p.s. Of course this is beyond us right now, but isn't the OS loaded from the CD? Is it theoretically possible to access the GPU without utilizing the CEL engine?

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Fri Sep 18, 2015 1:31 pm

Aer Fixus wrote:
blabla wrote:So i was able to get a first version working properly,
a playable alpha is now available for download.

There's one big issue with it though :
When there are too much blokcs (about 1 third of the playfield), it will flicker.

3DO weren't kidding when they said that their pixels routines were too slow...
Err WritePixel (Item bitmapItem,GrafCon *gc,Coord x, Coord y)

Description
This call writes a pixel to the display of the specified bitmap. The pixel is rendered in the foreground color of the GrafCon structure. It is rendered on the column and row specified by the x and y arguments respectively.

Notes
The current implementation of this routine is very slow. This will change in future releases.
Yeah. I was wondering what you used to write a pixel. I saw that in documentation and shied away from using it. I was going to work on writing pixels to a CEL/bitmap, using it like a backbuffer, and then rendering that to the screen, although that might be what they are doing already. But if they were just doing that, then I don't see why it would be so slow... We'd just need to know the formatting, no?

For my Tetris, I was likely going to have my implementation use CELs drawn to the screen using the CEL engine. Since it runs on the GPU, it should lighten the load from drawing on a pixel-per-pixel basis. And I can rotate/skew them if I want!

I also really need to do some benchmarking. How many CPU calculations can we realistically do at 30fps? How many CELs (GPU) can we render before taking a hit? How many together, etc. And framerate counters and stuff. Then, I could test exactly how slow WritePixel() is compared to other methods and seeing if any of us could make anything faster at all.
Speaking about the framerate, how could i lower it so i can do more stuff ?
I personally tried to do that but all i got are flickering blocks, just like before...
It honestly looks like they are drawing to a framebuffer but i could be wrong...
If 3DO is right then we should have cels of a size of 8x240 filling up the screen and draw on them :
it should be faster apparently than one huge cel of 320x240...

For now, using CEL graphics should be the way to go...
Too bad no graphics library i know support copying/clone of cels properly !
Aer Fixus wrote: p.s. Of course this is beyond us right now, but isn't the OS loaded from the CD? Is it theoretically possible to access the GPU without utilizing the CEL engine?
I heard it was difficult but possible to bypass the OS, but i'm honestly not sure the benefits of doing so
because it's not like the OS was as bad as the CDI's one. (where bypassing it was necessarry for less input latency)
Yes, it is loaded from the CD ; everything is in the System folder.
This is also where it loads the system fonts. (Kanji)
And this is also the reason why it takes so long to load a game on startup.

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Sat Sep 19, 2015 1:23 am

blabla wrote: Speaking about the framerate, how could i lower it so i can do more stuff ?
I personally tried to do that but all i got are flickering blocks, just like before...
It honestly looks like they are drawing to a framebuffer but i could be wrong...
If 3DO is right then we should have cels of a size of 8x240 filling up the screen and draw on them :
it should be faster apparently than one huge cel of 320x240...
Hmm... Frankly, I'm not sure. At first, I'd think that you'd be able to do as much as you wanted per frame, it would just go slower, but maybe 3DO did something in the OS to cut off frames that were taking too long. Maybe their update/game loop is separate from their draw loop. Since you are getting flickering, it could be trying to render your stuff before it is done writing the frame to the buffer (another reason I'd like to have control of my own backbuffer. I'd be able to release it when the frame is ready, not while some of my stuff is still drawing). There might be a variable somewhere for it, but I don't know right now.
blabla wrote:
Aer Fixus wrote: p.s. Of course this is beyond us right now, but isn't the OS loaded from the CD? Is it theoretically possible to access the GPU without utilizing the CEL engine?
I heard it was difficult but possible to bypass the OS, but i'm honestly not sure the benefits of doing so
because it's not like the OS was as bad as the CDI's one. (where bypassing it was necessarry for less input latency)
Yes, it is loaded from the CD ; everything is in the System folder.
This is also where it loads the system fonts. (Kanji)
And this is also the reason why it takes so long to load a game on startup.
Another reason to have a custom OS: just make something lightweight that does what we need it to do, nothing more. We don't need much for a functioning game, especially basic 2D ones. Loading all the 3D libraries just seems unnecessary for our projects. Plus, I'm not sure how much I trust the CEL engine. According to Burger Becky, they had memory leaks in String, so I'm not sure how much of the OS works as well as it could. In addition, it wasn't complete (at least not what we have access to). They were continuously updating it. The documentation even says that some stuff will be made better in the next version, or removed or what have you. That means that there are definitely things that aren't optimized like they should be.

And given the specs, I really think the system should be better than it is. And I think the OS is partly holding it back and adding bulk we don't need, but I could be completely wrong. In addition, if we gained access, we could send calculations to the GPUs that just can't be done on the CPU (think of the shaders!)

Also, If we gain access to the hardware, we open up so much! We could directly interface with the serial ports to make custom peripheral adapters, like memory cards or network adapters (once again, this is just as far out there as using a custom OS, but people have made network adapters for the NES). Something I've noticed is that the system resets when the eject button is pressed. If that's an action that the OS controls, it could allow for mid-game disc swapping for some cool/useful stuff (Vib Ribbon comes to mind).

-----

All this said, I think figuring out loading and playing sound effects is a high priority thing we can reasonably try to figure out in the near future. :lol:

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Sat Sep 19, 2015 3:26 am

Aer Fixus wrote: All this said, I think figuring out loading and playing sound effects is a high priority thing we can reasonably try to figure out in the near future. :lol:
I have already figured out how to play sounds or even music without much issues.
It's far from perfect though but it should do the job for a game like tetris.
3DO basically said that if we don't like their sound player, JUST DO IT YOURSELF DAMNIT !

All the sound code can be found in Source/3DO.c. (Actually, it's a modified version of my Gameblabla's Wrapper library)

I honestly think we should take a closer look at 3DO Doom's source code because it also shows us how to save to memory and crap like that.
The only problem is Burgerlib and it is quite bloated but we can take some parts, most notably the sound code.

Yeah, bypassing the OS would be nice but also a much harder task, i've seen it with liberis for PCFX.
I think the only homebrew not using the OS is that example with the sonic sprite programmed in ASM.

As for the framerate, i'll try to see if updating the screen several time instead
might do it.
I'll try to do it before i move to france. (i'll be unavailable for a while, unfortunely)

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Sun Sep 20, 2015 1:04 am

blabla wrote: I have already figured out how to play sounds or even music without much issues.
It's far from perfect though but it should do the job for a game like tetris.

All the sound code can be found in Source/3DO.c. (Actually, it's a modified version of my Gameblabla's Wrapper library)

I honestly think we should take a closer look at 3DO Doom's source code because it also shows us how to save to memory and crap like that.
The only problem is Burgerlib and it is quite bloated but we can take some parts, most notably the sound code.
Good to know. I'll look into it. What issues with the sound are there? I was under impression that they lagged behind a tad or something, but I'll try it out.

And yeah, Burgerlib will be hard to figure out, but a great reference that should help a lot with this stuff.

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Sun Sep 20, 2015 3:54 am

Aer Fixus wrote: Good to know. I'll look into it. What issues with the sound are there? I was under impression that they lagged behind a tad or something, but I'll try it out.
The issue with it is that sounds are not stored in RAM and only 4k (out of 32k) are allocated to them !
Music uses 16k for streaming but there is no such thing for sound effects.
This might be my last message before a while so don't bother answering me,
just do it.

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Sun Oct 04, 2015 11:25 pm

Just wanted to let you know that trying to update the screen several time
seems to have little to no effects.
Guess i'll have to find another tetris clone that is not using pixel drawing...

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Sun Oct 11, 2015 8:32 am

blabla wrote:Just wanted to let you know that trying to update the screen several time
seems to have little to no effects.
Guess i'll have to find another tetris clone that is not using pixel drawing...
I found this. Maybe I (or you, or someone else) can work with it to make my own backbuffer where I can write pixels to it faster than 3DO's function can. Then our pixel writing problem will be solved. If there is still flickering issues, we could even make it a double buffer and only release the frame when it's finished.

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Sun Oct 11, 2015 8:10 pm

It's really convenient that the website allows us to search the 3DO docs through google. Just starting to read this page shows a lot of insight on some important stuff regarding the frame buffer and the output stuff. For instance, our max framerate is 30 fps, because it outputs in 480i, even though our frame buffer is only 240p. (I'd live to change that so we can output 240p, but that's not really important at this moment)

It also explains the color-related stuff in detail. I'll be reading that over and over to see what I can soak up. I have no clue what you have and haven't looked into concerning this stuff as well. I'm just posting what I think is very relevant to our pixel situation.

Incidentally, the site uses 3D0, not 3DO.

User avatar
blabla
3DO ZERO USER
Posts: 142
Joined: Wed Feb 13, 2013 3:23 am
Location: France
Contact:

Re: LongTris (WIP)

Post by blabla » Sun Oct 11, 2015 8:48 pm

Aer Fixus wrote:It's really convenient that the website allows us to search the 3DO docs through google. Just starting to read this page shows a lot of insight on some important stuff regarding the frame buffer and the output stuff. For instance, our max framerate is 30 fps, because it outputs in 480i, even though our frame buffer is only 240p. (I'd live to change that so we can output 240p, but that's not really important at this moment)

It also explains the color-related stuff in detail. I'll be reading that over and over to see what I can soak up. I have no clue what you have and haven't looked into concerning this stuff as well. I'm just posting what I think is very relevant to our pixel situation.

Incidentally, the site uses 3D0, not 3DO.
Yes, i know about that but it's just that my english isn't that good and i understand half of it.
This is actually the leaked 3DO SDK Documentation that is on hackipedia, they just hosted it.

To disable the interlaced resolution, it is actually very simple :

Code: Select all

int32 DisableHAVG( Item screenItem )
int32 DisableVAVG( Item screenItem )
More about this here

airs also showed how you can disable this in hardware.
One possible drawback of this is that Need for Speed (which is using 480i) might not work properly...

I'm just not very experienced for low-level stuff i got to admit,
just because i'm active and made the first 3do homebrew for a while doesn't mean i'm that good.

The documentation is huge so if you stumble upon a pixel-rendering function for 3DO (either 3DO Doom or the doc),
come back here and we'll try it.

User avatar
Aer Fixus
3DO ZERO USER
Posts: 40
Joined: Thu Aug 21, 2014 10:59 pm

Re: LongTris (WIP)

Post by Aer Fixus » Mon Oct 12, 2015 3:34 am

I'm not the best at this stuff either :P

And that's great to know. I wonder if it actually displays in 60fps or if it's still 30fps. I did actually ready that post a while back, I just didn't remember that it had the functions for it.

I'll keep updating on what I find or accomplish. Maybe we want a separate thread for this stuff?

Also I find it really funny that they actually said "crispy pixels" in the official documentation.

Post Reply