Genny and 3D
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
That's pretty nifty! It works fine on emulation, but if you try to turn to the right from the starting position, it crashes on real hardware. Left is fine, but not right. Also, red wood paneling is kinda strange...
That crash is pretty hard - even reset won't get it running. You have to power off, and then back on.
EDIT: Wanna hear something weird? If I turn all the ways around to the left, then it works fine. I can keep going around the level without a crash. There's just something right there at the start that crashes when you try to turn right. Either turn a little to the right and take one step forward, or take one step forward and try to turn right, and BOOOOOOOOOOOOOM! If you do anything else, you're okay. Very strange...
That crash is pretty hard - even reset won't get it running. You have to power off, and then back on.
EDIT: Wanna hear something weird? If I turn all the ways around to the left, then it works fine. I can keep going around the level without a crash. There's just something right there at the start that crashes when you try to turn right. Either turn a little to the right and take one step forward, or take one step forward and try to turn right, and BOOOOOOOOOOOOOM! If you do anything else, you're okay. Very strange...
Thank you!
To be true, everything what is working perfectly in this version - its your work, and every single bug - mine work xD
Yes, those red wood paneling is my next fault - fixed pallete index right now, thx
I sent u lastest source in PM
Here is lastest binary (changed player angle variable type to unsigned, in hope it will help, and fixed pallete index):
raytest8.bin
To be true, everything what is working perfectly in this version - its your work, and every single bug - mine work xD
Yes, those red wood paneling is my next fault - fixed pallete index right now, thx
I sent u lastest source in PM
Here is lastest binary (changed player angle variable type to unsigned, in hope it will help, and fixed pallete index):
raytest8.bin
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
ZT is awesome !
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
No. 8 crashes within seconds of running... if you sit there, you remain sitting there as it's frozen. However, if you immediately start turning, you can get a couple turns before it freezes, but it ALWAYS freezes within a couple seconds. Now I'm wondering if the issue isn't interrupt related... maybe an issue with the vblank...
The every other column drawing I think is part of how colors are made since this is using "standard" video. On a TV with composite, this isn't very visible and changes the color compared to looking at an emulator.
You know, you could do the floor/ceiling color change rather easily using the other layer - make it lower priority than the layer you draw the walls in, and set the upper part to cells with the darker color, and the lower part to cells with the lighter color - only two cells needed for the entire floor and ceiling. You never have to worry about scrolling or redrawing.
EDIT: Very weird... no idea why it hangs. If you sit there and wait, it ALWAYS hangs within 4 seconds. If you move and keep moving, sometimes it will hang within 4 seconds, and sometimes it won't. If it doesn't hang within 4 seconds, you're safe and it NEVER hangs. I wonder if this is a bug in the sgdk version you are using... something to do with VDP DMA perhaps...
It's not the FPS counter as I commented that out, recompiled, and it still hangs.
One thing I noticed - the drawing is more of a slow-down than the raycasting. You get the highest FPS when the walls are way out in the distance - that means more time spent raycasting, but short walls mean fewer pixels to draw. When you get right up against a wall, the FPS is the lowest.
The every other column drawing I think is part of how colors are made since this is using "standard" video. On a TV with composite, this isn't very visible and changes the color compared to looking at an emulator.
You know, you could do the floor/ceiling color change rather easily using the other layer - make it lower priority than the layer you draw the walls in, and set the upper part to cells with the darker color, and the lower part to cells with the lighter color - only two cells needed for the entire floor and ceiling. You never have to worry about scrolling or redrawing.
EDIT: Very weird... no idea why it hangs. If you sit there and wait, it ALWAYS hangs within 4 seconds. If you move and keep moving, sometimes it will hang within 4 seconds, and sometimes it won't. If it doesn't hang within 4 seconds, you're safe and it NEVER hangs. I wonder if this is a bug in the sgdk version you are using... something to do with VDP DMA perhaps...
It's not the FPS counter as I commented that out, recompiled, and it still hangs.
One thing I noticed - the drawing is more of a slow-down than the raycasting. You get the highest FPS when the walls are way out in the distance - that means more time spent raycasting, but short walls mean fewer pixels to draw. When you get right up against a wall, the FPS is the lowest.
greatkreator Thank you! Yes, ray casting engine using tile rendering sounds very interesting - and for sure it will be much faster than bitmap pixel rendering.
djcouchycouch Thank you! About every other vertical line drawing - its how bitmap routines works, i.e. bitmap width is 128px, but its stretched to 256 px width, without doubling vertical lines. I again, changed bitmap routines to my own slow version, it works at 1:1 size (128x64). Hope maybe it will not hangs on real hardware..
Chilly Willy Thank you! Yes, i thought about using other plan for floor/ceiling placement - but now i think its have no sense, because my version even dont work on real hardware And again - ur version looks perfect! And, yes - seems that slow part is pixel drawing, not the ray casting itself.
to all If not checked yet - pls, check Chilly Willy's Direct Color DMA version of this raycasting engine for sega cd (works only on real hardware) - its looks awesome!
this version with my setBMP() (much slower than sgdk bitmap routines):
raytest8bmp.bin
djcouchycouch Thank you! About every other vertical line drawing - its how bitmap routines works, i.e. bitmap width is 128px, but its stretched to 256 px width, without doubling vertical lines. I again, changed bitmap routines to my own slow version, it works at 1:1 size (128x64). Hope maybe it will not hangs on real hardware..
Chilly Willy Thank you! Yes, i thought about using other plan for floor/ceiling placement - but now i think its have no sense, because my version even dont work on real hardware And again - ur version looks perfect! And, yes - seems that slow part is pixel drawing, not the ray casting itself.
to all If not checked yet - pls, check Chilly Willy's Direct Color DMA version of this raycasting engine for sega cd (works only on real hardware) - its looks awesome!
this version with my setBMP() (much slower than sgdk bitmap routines):
raytest8bmp.bin
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Okay, here's peekpoke's raycaster updated to the current sgdk:
raytest8-joe.7z
Found some "weird" things in the current sgdk while doing this... first, there's some obscure timing bug in the VDP functions somewhere. I have to do this to get the demo to work on real hardware:
See those hw_delay() calls? All three are needed and MUST be two calls to VDP_drawText() or it fails on real hardware. What you see without any one of them is the screen does a slow fade from black to the gray, and hangs. It's not frozen as you can reset, but it doesn't run. It doesn't show on emulators, only on real hardware.
Next, see that VDP_setPalette_old()? That's called VDP_setPalette() in vdp.h. One or the other needs to be changed to match the other.
Next, in rom_head.c, you have this
See that "char serial[16];"? It needs to be serial[14]. The rest of the header is two off because of that.
Just minor problems other than the weird VDP issue. The BMP code is much cleaner now than in the old version of sgdk. The main loop in the demo is nice and clean, and it runs at almost the exact same speed as the old devkit.
raytest8-joe.7z
Found some "weird" things in the current sgdk while doing this... first, there's some obscure timing bug in the VDP functions somewhere. I have to do this to get the demo to work on real hardware:
Code: Select all
void hw_delay()
{
VDP_drawText(" ", 2, 2);
VDP_drawText(" ", 2, 2);
}
int main()
{
char str[16];
textures[0] = 0;
textures[1] = &tex_wood;
textures[2] = &tex_bricks;
textures[3] = &tex_bird;
textures[4] = &tex_bricks2;
hw_delay();
px = 112;
py = 260;
pa = 386;
VDP_setScreenWidth256();
VDP_setHInterrupt(0);
VDP_setHilightShadow(0);
hw_delay();
VDP_setPalette_old(0,palette0);
hw_delay();
BMP_init();
Next, see that VDP_setPalette_old()? That's called VDP_setPalette() in vdp.h. One or the other needs to be changed to match the other.
Next, in rom_head.c, you have this
Code: Select all
const struct
{
char console[16]; /* Console Name (16) */
char copyright[16]; /* Copyright Information (16) */
char title_local[48]; /* Domestic Name (48) */
char title_int[48]; /* Overseas Name (48) */
char serial[16]; /* Serial Number (2, 14) */
Just minor problems other than the weird VDP issue. The BMP code is much cleaner now than in the old version of sgdk. The main loop in the demo is nice and clean, and it runs at almost the exact same speed as the old devkit.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
That weird timing issues with SGDK are probably related to the BMP_init() call. I made major changes in the BMP engine code and i fixed some problems in initialization code which may cause hang because of interrupt happening during init.
The next version will have cleaner, simpler and faster bitmap mode, i hope to make a release soon so you can test it with the raycaster
Stupid typo about the rom header, need to fix that quickly
The next version will have cleaner, simpler and faster bitmap mode, i hope to make a release soon so you can test it with the raycaster
Stupid typo about the rom header, need to fix that quickly
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Well, we have a way to try it to see if it fixes the issue. Just mention the BMP fix when you update the repo and I'll try it again.Stef wrote:That weird timing issues with SGDK are probably related to the BMP_init() call. I made major changes in the BMP engine code and i fixed some problems in initialization code which may cause hang because of interrupt happening during init.
The next version will have cleaner, simpler and faster bitmap mode, i hope to make a release soon so you can test it with the raycaster
Stupid typo about the rom header, need to fix that quickly
The rom header wasn't a big deal because the only parts that REALLY matter are the exception table and the "SEGA" at 0x100 for TMSS. NOTHING else matters to the console - it's all the rom itself... or for emulators and flash cards which expect a "standard" header.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
I posted a new version, i think it's good enough to deserve a release.
Mainly bitmap and maths 3D stuff but that may interest here =)
Mainly bitmap and maths 3D stuff but that may interest here =)