This'll probably go nowhere...

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, [ProToS], lp, moondog/.tSCc., Moderator Team

Post Reply
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

This'll probably go nowhere...

Post by LaceySnr »

But I wanted to write a basic software 3d again, and figured it might be fun to do it on the Falcon in TC mode (albeit in C, for some modicum of portability). It's not fast or pretty, and may well never be either of those two things, but thought I might post some updates here all the same. Finally got my triangle raster quirks worked out tonight, previously I had triangles vanishing under very specific conditions. So far it can load an .obj file, render it without any kind of depth testing, crash spectacularly if a triangle goes out of the screen and that's about it :D
Icosphere.gif
You do not have the required permissions to view the files attached to this post.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3629
Joined: Sat Jun 30, 2012 9:33 am

Re: This'll probably go nowhere...

Post by dml »

:thumbs:

Nice work! Looks pretty tidy.

Tip - if you ADD the pixels to the fraembuffer you should be able to see edge overlap errors, if there are any. Providing you backface cull and test with a convex shape anyway.

On the other hand I don't want to drive you insane chasing down tiny glitches :) you can always focus on something more fun!
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 767
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: This'll probably go nowhere...

Post by Anima »

Well, I like it. In fact it doesn't have to be fast or whatever as long as you and others have fun watching and/or programming new stuff on our ancient machines. So thumbs up!

So you can load Wavefront object files with your program?
User avatar
mrbombermillzy
Captain Atari
Captain Atari
Posts: 367
Joined: Tue Sep 13, 2016 9:24 am

Re: This'll probably go nowhere...

Post by mrbombermillzy »

Augmenting what Anima said: If everyone 'had a go' like this, then we would be a thriving Atari scene once again.

Plus you never know what techniques you may uncover and/or what might lead to what.

Carry on I say! ;)
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Anima wrote: Thu Jul 02, 2020 3:00 pm Well, I like it. In fact it doesn't have to be fast or whatever as long as you and others have fun watching and/or programming new stuff on our ancient machines. So thumbs up!

So you can load Wavefront object files with your program?
Basic ones :) It only loads the vertex and face information. I calculate face normals myself for backface culling and lighting as obj's only provide vertex normals and not sure I'll have the grunt available for smooth shading.
dml wrote: Thu Jul 02, 2020 2:48 pm Tip - if you ADD the pixels to the fraembuffer you should be able to see edge overlap errors, if there are any. Providing you backface cull and test with a convex shape anyway.
Yeah I've done that in the past. I think there's a tiny bit of overdraw at the moment but nothing crazy. The biggest performance killer is that until I have a full scene I'm just memset'ing the entire buffer to black before doing any drawing. Well, it's that and all the multiplications :P
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 767
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: This'll probably go nowhere...

Post by Anima »

LaceySnr wrote: Fri Jul 03, 2020 12:10 am Basic ones :) It only loads the vertex and face information. I calculate face normals myself for backface culling and lighting as obj's only provide vertex normals and not sure I'll have the grunt available for smooth shading.
I managed to extract the 3D objects from some arcade games and converted them to the Wavefront format. The colors are not correct, though. Those should look nice with flat shading. ;)

Air Combat
Cyber Sled
Solvalou
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Reckon I might need to sort out some proper z-buffering or something to make these look good, but couldn't resist taking a crack. Pretty sure I'm dropping a few tris with backface culling turned on so either I have a bug or some of the faces are wound in different directions. Will keep poking about :)
ace1.png
ace2.png
ace3.png
You do not have the required permissions to view the files attached to this post.
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 767
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: This'll probably go nowhere...

Post by Anima »

Nice! :cheers:

Well, I just remember that the models might contain quads so do you discard them while parsing?
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Ah, I didn't look in the file in too much detail - that may well be it. I do some pretty basic scanf parsing, might well just be discarding the fourth index. Will take a look - should be easy enough to create two triangles for a quad, will just have to make sure I get the winding correct.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Anima wrote: Fri Jul 03, 2020 1:06 pm Well, I just remember that the models might contain quads so do you discard them while parsing?
You were correct! There weren't many in the file, but I added support for them and it's filled in a few gaps. Spent most of the last week working on a Windows tool that leverages the same loading code etc. which makes it all much easier to debug. Hopefully get some basic BSP stuff going thanks to DML's advice and have a flat shaded version soon that doesn't have all the z-fighting issues!
ace5.png
You do not have the required permissions to view the files attached to this post.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Well it's been a while, and it's involved writing a tool in windows to load .OBJ files and export my own format, but on DML's advice I created a simple BSP format for models to help render nicely without a z-buffer. I've not added poly splitting yet which will be needed for better output, but already it's clearly better than before.

.OBJ File - rendered in the order the faces are listed in the file:
Ace_Obj.png
.LTO (Lacey Tree Object - yes I'm a dumbass who names things after myself) - rendered through a BSP hierarchy where the planes are all axis aligned:
Ace_Tree.png
You do not have the required permissions to view the files attached to this post.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3629
Joined: Sat Jun 30, 2012 9:33 am

Re: This'll probably go nowhere...

Post by dml »

Nice work! You can probably do all sorts of stuff with that now :-)

If you want to squeeze everything into the i-cache you can just walk the bsp and (for example) output some face pointers or indices only. You can then draw the faces in a separate pass. Also makes measurements simpler if you are optimizing pieces at a time.

Poly splitting should tidy up the remaining z-ordering problems
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

dml wrote: Sun Aug 23, 2020 8:01 pm If you want to squeeze everything into the i-cache you can just walk the bsp and (for example) output some face pointers or indices only. You can then draw the faces in a separate pass. Also makes measurements simpler if you are optimizing pieces at a time.
I suspect because of my C usage I'm nowhere near optimised in any of my loops, but this makes a lot of sense - will do that for sure. Went for the simplest option to start with but somehow this didn't even occur to me. I did save some time by realising that I was wasting effort transforming all the face normals for lighting, now I just transform the light vector by the inverse of the object matrix instead so I can use the normals without transformation.

Once I've done the poly splitting I'll have to do 3D and screen clipping - right now I have to make sure everything's staying within the frame bounds :lol:
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Welp, finally got the poly splitting 'done' for the BSP generation, it's creating a few too many faces for my liking but the tweaking could go on forever. Got some gaps between polys at times, going to have to work out if that's precision or my 2d drawing at fault, but happy enough for now!
Ace_Tree_New4.png
Ace_Tree_New3.png
You do not have the required permissions to view the files attached to this post.
User avatar
dhedberg
Atari God
Atari God
Posts: 1206
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: This'll probably go nowhere...

Post by dhedberg »

Great! Precision should not be a problem. The reason for the gaps is most likely one (or both) of the following:

1. The polygon rasterizer/filler lacks a proper pixel definition. You need to decide if a pixel should be included in the left or right edge, as well as top or bottom edge. If you draw a line from pixel 4 to 12, what pixels are filled?
2. Adjacent polygons do not share vertices and hence the shared slope of the polygons will be slightly different for each polygon. This will lead to overlapped or missed pixels.
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2229
Joined: Sun Jul 31, 2011 1:11 pm

Re: This'll probably go nowhere...

Post by Eero Tamminen »

Nice to see Hatari being used for such a nice thing. :-)

Are you using DSP for something, or do you just disable Hatari DSP emulation for some extra emulation speed?
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Thanks for the tips Daniel, I suspect it is largely a case of #1, I did do a few quick tests when I wrote the rasteriser but I suspect there's a case or two where it's not correct.

Eero, I'm not using the DSP yet, though that's on the 'todo' list as I could definitely use the speed boost it'd offer. I only got around to trying this on hardware the other night and discovered that it doesn't work - causes a crash - so need to do some more testing and work out what might be different there. Using a GEMDOS drive is working really well as I'm compiling with Pure C (not cross compiling) - I can just keep it open with the main file loaded, and any other code changes I made get picked up automatically :)
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2229
Joined: Sun Jul 31, 2011 1:11 pm

Re: This'll probably go nowhere...

Post by Eero Tamminen »

If you aren't using DSP, Hatari Falcon emulation works much faster when you disable it ("--dsp none").

Issues that could explain Hatari behaving differently than real Falcon:
* Having different machine config (e.g. less memory, different TOS version or display)
* Extra SW started at boot which interferes with your program (e.g. some HD drivers use some of the timers) - try with HD image and same driver as on real Falcon
* Something related to MMU (better use Git version of Hatari when enabling MMU as there were several 030 MMU related fixes after v2.2.1)
* Not using cycle-exact mode in Hatari i.e. not enabling CPU cache emulation

=> GEMDOS drive is really nice, but before moving to real HW, I'd test with HD image & real Falcon HD driver too.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Thanks Eero, will work my way through that and see where it might be going wrong. Of course it could be my Falcon too, it can't get through the Joy demo for some reason so it's not entirely healthy.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2229
Joined: Sun Jul 31, 2011 1:11 pm

Re: This'll probably go nowhere...

Post by Eero Tamminen »

Btw. If you aren't using Hatari Git version, Nicolas is planning on releasing new Hatari version soon. It has following improvements compared to v2.2.1: https://hatari.tuxfamily.org/doc/release-notes.txt
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

Eero Tamminen wrote: Wed Oct 14, 2020 11:46 pm Btw. If you aren't using Hatari Git version, Nicolas is planning on releasing new Hatari version soon. It has following improvements compared to v2.2.1: https://hatari.tuxfamily.org/doc/release-notes.txt
I'll be sure to check that out! Stalled a bit again recently (lock down was necessitating more beer and games over hard thinking) but just worked out why my program was crashing on the real hardware: it was failing to load the data files and I wasn't handling that scenario properly. The interesting part though is why it was failing and I guess this may be related to GEMDOS or some other part of Hatari in a way?

Basically I had paths like this:

fp = fopen("data/cube.lto");

Which always worked fine under Hatari (even under windows with that '/')... on the hardware I need to use escaped backslashes:

fp = fopen("data\\cube.lto");

Maybe it's just Pure C versions or HDD drivers or something but I thought you'd be interested to know.
User avatar
sporniket
Atari freak
Atari freak
Posts: 69
Joined: Fri Feb 16, 2018 5:39 pm

Re: This'll probably go nowhere...

Post by sporniket »

LaceySnr wrote: Mon Nov 02, 2020 10:48 am
Basically I had paths like this:

fp = fopen("data/cube.lto");

Which always worked fine under Hatari (even under windows with that '/')... on the hardware I need to use escaped backslashes:

fp = fopen("data\\cube.lto");

Maybe it's just Pure C versions or HDD drivers or something but I thought you'd be interested to know.
I recently read that that is a gotcha when using Hatari Gemdos drive emulation. If I remember correctly what I read, when using an ACSI image file as drive instead of gemdos emulation, the program will reproduce the error you got on real hardware.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2229
Joined: Sun Jul 31, 2011 1:11 pm

Re: This'll probably go nowhere...

Post by Eero Tamminen »

LaceySnr wrote: Mon Nov 02, 2020 10:48 am just worked out why my program was crashing on the real hardware: it was failing to load the data files and I wasn't handling that scenario properly. The interesting part though is why it was failing and I guess this may be related to GEMDOS or some other part of Hatari in a way?

Basically I had paths like this:

fp = fopen("data/cube.lto");

Which always worked fine under Hatari (even under windows with that '/')... on the hardware I need to use escaped backslashes:

fp = fopen("data\\cube.lto");
GEMDOS HD comparison is quite complex because both Atari side file names need mangling (same as TOS does), and host side names need mangling (for char set conversion, to support longer than 8+3 change file names, and map invalid char), before they're matched case-insensitively (as that's not supported e.g. by normal Linux file systems).

The problem here is that host systems recognize '/' as path separator although it's not on Atari. I think the reason why it works also on Windows, is your Hatari binary being linked against some Windows library that does automatic / -> \ path conversion for file names.

If you want to propose a patch to: https://git.tuxfamily.org/hatari/hatari ... c/gemdos.c

You would need to change all checks for '\\' in GemDOS_CreateHardDriveFileName() function to check also for PATHSEP (host path separator), and do some testing for the change before posting the patch.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2229
Joined: Sun Jul 31, 2011 1:11 pm

Re: This'll probably go nowhere...

Post by Eero Tamminen »

sporniket wrote: Mon Nov 02, 2020 3:23 pm I recently read that that is a gotcha when using Hatari Gemdos drive emulation. If I remember correctly what I read, when using an ACSI image file as drive instead of gemdos emulation, the program will reproduce the error you got on real hardware.
Yes, with (floppy, IDE, ACSI, SCSI) images, Hatari does only the block level HW operations, TOS will handle rest => that will catch any issues in file handling that GEMDOS HD emulation missed.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: This'll probably go nowhere...

Post by LaceySnr »

That's all useful info to know, thanks! It's no big deal, and I'm surprised I didn't spot it before to be honest. Not sure I'd have any time soon to issue a patch but perhaps this thread might save at least one other person down the line from making the same mistakes as me :)
Post Reply

Return to “Professionals”