Author
Windows XP, VC++ Express
I would like to make a 3D Engine in C++.
Even if it was just wireframes it would be cool.
I don't want to use other librarys I want to learn to do one myself.
The reason is I also know Asm for my Ti-84+ and would like to know at least the basics of a 3d Engine to make my own.
Another reason is that I would like to make something that makes 3D animations, that I can call my own.
Thanks anyone who posts.
Start with nehe.gamedev.net. That was what I started from and in a year or two I managed to write an engine with all the shaders and stuff.
Are you talking about making a 3D engine that runs on a 3D API like Direct3D, or are you talking about making a full-blown software rasterizer here?
Quote:Original post by MJP
Are you talking about making a 3D engine that runs on a 3D API like Direct3D, or are you talking about making a full-blown software rasterizer here?
Let's hope he means 3D engine over an API. Honestly, making your own actual API or something without accessing a current API is quite near impossible unless you're one great programmer or on a great team.
You could build a simple engine in something like DirectX or XNA and write your own content pipeline to try to introduce your own specific type of animation or whatever it is you're looking at bringing in. The hardest part wouldn't be building the animation but rather processing it in an engine.
If you want to build your own API or rasterizer you're probably going to need to know very low level code, because I think most API's access hardware almost directly.
Author
Yes a full blown API of my own.
Like I said just learning to do wire frames would be neat.
If thats not possible
What about a 3D Engine in Asm for a Ti-84+ calc.
I already know Zilog Z180 Assembly.
Like I said just learning to do wire frames would be neat.
If thats not possible
What about a 3D Engine in Asm for a Ti-84+ calc.
I already know Zilog Z180 Assembly.
Hi,
Making your own 3D engine is very well possible. As long as your demands aren't to high. Of course its much easier to use an API, but that should stop you from triing. After all, doing things yourself is fun! Probably many of us have written a small 3D rasteriser at some point (At least I did, one fancy fixed point triangle plotter :D ). Actually, in my own Direct3D based engine, I have my own clipping and raster routines for some specific tasks (High map management, static decal construction etc).
For your Ti 84+ calculator... I have only experience with a Ti 83, but only clearing the screen costs considerable processing power, so having a 3D engine with fully 3D objects is probably not possible in real time, even with only wireframe rendering. Although you could try, its in interesting project. I think your Ti 84+ has native matrix support, which might come in handy.
By the way, I hope you program assembler and not the native basic language of your Ti 84+. In my high-school years, i once programmed a little raytracer for my Ti 83 in basic. only rendering one dittered sphere was extremely slow! (ok, i admin, a ray tracer on a black-and-white calculator is a stupid idea, but the lecture was soooo boring)
It probably might be a good idea to get some inspiration from games as Wolfenstein 3D, as these games where build for very low performance systems. These games give the illusion of 3D, without the actual calculations needed for a full 3D engine.
For information about 3D software rendering, Building a 3D Portal Engine. This is a nice introduction into software rendering. This was actually one of the first articles I read on the topic and I learned a lot from this one.
succes
[Edited by - dietepiet on August 18, 2008 3:07:44 PM]
Making your own 3D engine is very well possible. As long as your demands aren't to high. Of course its much easier to use an API, but that should stop you from triing. After all, doing things yourself is fun! Probably many of us have written a small 3D rasteriser at some point (At least I did, one fancy fixed point triangle plotter :D ). Actually, in my own Direct3D based engine, I have my own clipping and raster routines for some specific tasks (High map management, static decal construction etc).
For your Ti 84+ calculator... I have only experience with a Ti 83, but only clearing the screen costs considerable processing power, so having a 3D engine with fully 3D objects is probably not possible in real time, even with only wireframe rendering. Although you could try, its in interesting project. I think your Ti 84+ has native matrix support, which might come in handy.
By the way, I hope you program assembler and not the native basic language of your Ti 84+. In my high-school years, i once programmed a little raytracer for my Ti 83 in basic. only rendering one dittered sphere was extremely slow! (ok, i admin, a ray tracer on a black-and-white calculator is a stupid idea, but the lecture was soooo boring)
It probably might be a good idea to get some inspiration from games as Wolfenstein 3D, as these games where build for very low performance systems. These games give the illusion of 3D, without the actual calculations needed for a full 3D engine.
For information about 3D software rendering, Building a 3D Portal Engine. This is a nice introduction into software rendering. This was actually one of the first articles I read on the topic and I learned a lot from this one.
succes
[Edited by - dietepiet on August 18, 2008 3:07:44 PM]
If you don't use a 3D API, you won't be able to access any 3D hardware. This means making an all-software rasterizer. This is certainly doable and there are resources available for this...but it's very difficult and the only benefit would be educational.
You should check out Chris Hecker's series for a place to start, and perhaps also this article down the road.
You should check out Chris Hecker's series for a place to start, and perhaps also this article down the road.
There's a lot of posts here that make writing your own software renderer sound like an unreasonably difficult task, but I assure you it is not.
If you look at, say, Quake 2 in software mode -- which runs smoothly at 640x480 on a slow Pentium 2, and you'd be satisfied with that level of visuals, then you consider that now even 5 year old CPUs are 5-6 times as fast, and probably twice as potent per clock-cycle, you have 10-12 times the processing power that made Quake 2 run. You don't even have to touch assembly these days (as long as you're smart with your C, C++ or other language of choice) to get that level of visual and geometric quality.
There's a lot of good information on software rendering out on the net, including the "black book" -- as well as some classic Texts, such as Foley and Van Damm.
The biggest initial hurdle you'll face is setting up some sort of framebuffer for yourself. Because Windows doesn't allow you to access the video hardware directly, you'll have to create a window, create a DIB (Device Independent Bitmap), grab a pointer to the DIB in order to use it as the framebuffer, and then BitBlt the DIB to the window in order to show it. This process will change slightly for different platforms such as Linux or MacOS, but the basic steps are essentially the same and will provide a very close analog to raw, hardware framebuffer access.
Read up and get cracking.
If you look at, say, Quake 2 in software mode -- which runs smoothly at 640x480 on a slow Pentium 2, and you'd be satisfied with that level of visuals, then you consider that now even 5 year old CPUs are 5-6 times as fast, and probably twice as potent per clock-cycle, you have 10-12 times the processing power that made Quake 2 run. You don't even have to touch assembly these days (as long as you're smart with your C, C++ or other language of choice) to get that level of visual and geometric quality.
There's a lot of good information on software rendering out on the net, including the "black book" -- as well as some classic Texts, such as Foley and Van Damm.
The biggest initial hurdle you'll face is setting up some sort of framebuffer for yourself. Because Windows doesn't allow you to access the video hardware directly, you'll have to create a window, create a DIB (Device Independent Bitmap), grab a pointer to the DIB in order to use it as the framebuffer, and then BitBlt the DIB to the window in order to show it. This process will change slightly for different platforms such as Linux or MacOS, but the basic steps are essentially the same and will provide a very close analog to raw, hardware framebuffer access.
Read up and get cracking.
Quote:Original post by Ravyne
The biggest initial hurdle you'll face is setting up some sort of framebuffer for yourself. Because Windows doesn't allow you to access the video hardware directly, you'll have to create a window, create a DIB (Device Independent Bitmap), grab a pointer to the DIB in order to use it as the framebuffer, and then BitBlt the DIB to the window in order to show it. This process will change slightly for different platforms such as Linux or MacOS, but the basic steps are essentially the same and will provide a very close analog to raw, hardware framebuffer access.
Perhaps PixelToaster would be handy there.
Software rendering tutorial (its a series).
Looks like you are interested in the low level pixel pushing math, not using accelerated graphics or anything.
FWIW, the "lowest level" for a TI-84 would be software rendering. The modern "lowest level" would be DirectX or OpenGL, which are effectively a thin wrapper over the graphics card hardware. It doesn't seem low level, but you really can't get any lower.
Looks like you are interested in the low level pixel pushing math, not using accelerated graphics or anything.
FWIW, the "lowest level" for a TI-84 would be software rendering. The modern "lowest level" would be DirectX or OpenGL, which are effectively a thin wrapper over the graphics card hardware. It doesn't seem low level, but you really can't get any lower.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
