Graphic Engine môn Công nghệ thông tin | Trường đại học Kinh Doanh và Công Nghệ Hà Nội

This chapter will begin by brie昀氀y introducing some basicrendering concepts as well as a discussion on the models and textures used in the game, before going into detail about several techniques that we felt were relevant to explore in order to create interes琀椀ng graphical e昀昀ects. Tài liệu giúp bạn tham  khảo, ôn tập và đạt kết quả cao. Mời đọc đón xem!

12 6 lượt tải Tải xuống
Chia sẻ Báo cáo tài liệu

Môn: Công nghệ thông tin (HUBT)

Trường: Đại học Kinh Doanh và Công Nghệ Hà Nội

Thông tin:

5 trang 2 tuần trước

Tác giả:

Profile Lan Anh Trần
lOMoARcPSD| 48704538
Graphic Engine
This chapter will begin by brie 昀氀 y introducing some basic rendering concepts
as well as a discussion on the models and textures used in the game, before going
into detail about several techniques that we felt were relevant to explore in order
to create interes 琀椀 ng graphical e 昀昀 ects. All sec 琀椀 ons, except for the
rendering introduc 琀椀 on, will also present and discuss the results a 昀琀 er
having been implemented in the game.
Three-dimensional graphics are typically represented in one of three ways:
triangles, voxels, or curve surfaces. Triangles are probably the most common of
the three, and the graphics hardware is op 琀椀 mized toward processing these.
Each triangle is represented by three ver 琀椀 ces, which are points in three-
dimensional space. Voxels, in the context of real-琀椀 me graphics, are essen 琀
椀 ally cubes on a grid. In contrast to triangles, which are very good at represen
琀椀 ng graphics with large amounts of empty space, voxels are superior for
represen 琀椀 ng graphics with large amounts of non-empty space, which makes
voxels common for terrain rendering. Curve surfaces are de 昀椀 ned by curves,
and can as such represent smooth detail several magnitudes more complex than
triangles and voxels, but lack the 昀氀 exibility of the previous two when the
surface is not smooth.
When rendering three-dimensional graphics in real-琀椀 me, there are several
steps that are commonly referred to as the graphics pipeline [Marroquim 2009].
Since this project uses the XNA framework, and by extension, Direct3D, we did
not have to implement this pipeline ourselves. Direct3D uses a so called shader
language called HLSL (High Level Shader Language). This shader language deals
with two steps of the graphics pipeline and consists of two parts: the vertex
shader and the pixel shader. There is also a third type of shader, called the
geometry shader, which will not be covered here. The vertex shader, as the name
implies, deals with transforming and shading the ver 琀椀 ces. This involves
lOMoARcPSD| 48704538
transforma 琀椀 on of the ver 琀椀 ces’ posi 琀椀 ons from world space to
screen space, calcula 琀椀 on of normals, and the depth value of the ver 琀椀
ces, among other things. This informa 琀椀 on is then passed on to the pixel
shader, which is executed for each pixel on the screen that contains any
geometry. The pixel shader outputs color data for each pixel on the screen, and
can generate this color data in a mul 琀椀 ple of ways, including looking up data
from textures that have been input, calcula 琀椀 ng complex shading opera 琀椀
ons based on the informa 琀椀 on passed on from the vertex shader, and even
genera 琀椀 ng special e 昀昀 ects that can be applied to the whole screen
(postprocessing).
User Interface & Input
Good input management is important for several reasons;like most other game
architecture problems, the code needs to be easily extensible and modi 昀椀
able. It is alsopreferable if the input can be customized by the user.
However, because this is just a simple game, we have op 琀椀 mized the handling
of movement events in the game by touching the screen with your 昀椀 nger and
the game objects will move based on your wishes.
Example:( đợi Huy code xong giao diện)
Besides, we also op 琀椀 mize the UI as much as possible. Here is the image when
the game runs:(đợi Huy code xong r chụp ảnh)
lOMoARcPSD| 48704538
Coding Standards
Coding standards are a set of rules and conven 琀椀 ons that de 昀椀 ne how to
write and format your code. They help you to keep your code consistent,
readable, and organized. They also make it easier for other programmers to
understand and modify your code, which is especially important for collabora 琀
椀 ve projects. There are many coding standards but we have tried to stay as
close to C++ and objectoriented programming standards as possible. The rules we
have implemented can be detailed as follows:
Every comma is followed by a space, for example doStu 昀昀(5, 7, 8)
Spaces around operators, for example: 5 + 7 instead of 5+7
Tabs have the same size as four spaces. Tabs are stored as tabs, not as spaces.
Func 琀椀 ons and sta 琀椀 c variables are in the same order in the .h and .cpp 昀
椀 les.
Try to make short func 琀椀 ons, preferably no more than 50 lines.
Avoid making very large classes. Split a class whenever you an 琀椀 cipate the
class will grow a lot and you can cleanly split it. In general, try to keep class sizes
below 750 lines.
lOMoARcPSD| 48704538
Don't write lines that are longer than what 昀椀 ts on a normal 1920*1080
screen.
Names of variables and func 琀椀 ons should be descrip 琀椀 ve. Long names are
no problem. Only use abbrevia 琀椀 ons if they are very clear and commonly
known.
The 昀椀 rst le 琀琀 er of classes, structs and enum type names is a capital.
Variables and func 琀椀 ons start without a capital. Each further word in a name
starts with a cap 琀椀 cal. Don't use underscores ( _ ) in variable names.
Implementa 琀椀 ons of func 琀椀 ons are never in .h-昀椀 les.
Variables inside func 琀椀 ons are declared at the point where they are needed,
not all of them at the start of the func 琀椀 on.
Never ever even think of using go-to statements.
Use override and 昀椀 nal wherever applicable.
If a func 琀椀 on is virtual, the virtual keyword should always be added to it, so
not only in the parent class, but also in each version of the func 琀椀 on in the
child classes.
Development Tools
lOMoARcPSD| 48704538
Game dev tools are cri 琀椀 cal for suppor 琀椀 ng di 昀昀 erent stages of game
development. They help facilitate the crea 琀椀 on of character models,
gameplay physics, AI for non-playable characters (NPCs), icons, menus, sound e
昀昀 ects, help screens, bu 琀琀 ons, and even backend systems integral to game
development.
With the rapid advancement of technology, every year a new wave of video game
development tools emerge to join the tried and tested tools all game developers
can’t live without. In recent years, that’s included tools that leverage AI to, not
only streamline the development process, but also push the boundaries of what's
possible in game crea 琀椀 on.
From assis 琀椀 ng in genera 琀椀 ng landscapes to building autonomous AI NPCs
players can talk to voice-to-voice, AI-powered tools are 昀椀 nding a place
alongside game developer tools that have been around for decades.
In this project, because it is a simple game with few features, we have chosen
some outstanding tools as follows:
Abode Photoshop
Visual Studio
Github
| 1/5
| | Tải xuống

Có thể bạn quan tâm:

Preview text:

lOMoAR cPSD| 48704538 Graphic Engine
This chapter will begin by brie 昀氀 y introducing some basic rendering concepts
as well as a discussion on the models and textures used in the game, before going
into detail about several techniques that we felt were relevant to explore in order
to create interes 琀椀 ng graphical e 昀昀 ects. All sec 琀椀 ons, except for the
rendering introduc 琀椀 on, will also present and discuss the results a 昀琀 er
having been implemented in the game.
Three-dimensional graphics are typically represented in one of three ways:
triangles, voxels, or curve surfaces. Triangles are probably the most common of
the three, and the graphics hardware is op 琀椀 mized toward processing these.
Each triangle is represented by three ver 琀椀 ces, which are points in three-
dimensional space. Voxels, in the context of real-琀椀 me graphics, are essen 琀
椀 ally cubes on a grid. In contrast to triangles, which are very good at represen
琀椀 ng graphics with large amounts of empty space, voxels are superior for
represen 琀椀 ng graphics with large amounts of non-empty space, which makes
voxels common for terrain rendering. Curve surfaces are de 昀椀 ned by curves,
and can as such represent smooth detail several magnitudes more complex than
triangles and voxels, but lack the 昀氀 exibility of the previous two when the surface is not smooth.
When rendering three-dimensional graphics in real-琀椀 me, there are several
steps that are commonly referred to as the graphics pipeline [Marroquim 2009].
Since this project uses the XNA framework, and by extension, Direct3D, we did
not have to implement this pipeline ourselves. Direct3D uses a so called shader
language called HLSL (High Level Shader Language). This shader language deals
with two steps of the graphics pipeline and consists of two parts: the vertex
shader and the pixel shader. There is also a third type of shader, called the
geometry shader, which will not be covered here. The vertex shader, as the name
implies, deals with transforming and shading the ver 琀椀 ces. This involves lOMoAR cPSD| 48704538
transforma 琀椀 on of the ver 琀椀 ces’ posi 琀椀 ons from world space to
screen space, calcula 琀椀 on of normals, and the depth value of the ver 琀椀
ces, among other things. This informa 琀椀 on is then passed on to the pixel
shader, which is executed for each pixel on the screen that contains any
geometry. The pixel shader outputs color data for each pixel on the screen, and
can generate this color data in a mul 琀椀 ple of ways, including looking up data
from textures that have been input, calcula 琀椀 ng complex shading opera 琀椀
ons based on the informa 琀椀 on passed on from the vertex shader, and even
genera 琀椀 ng special e 昀昀 ects that can be applied to the whole screen (postprocessing). User Interface & Input
Good input management is important for several reasons;like most other game
architecture problems, the code needs to be easily extensible and modi 昀椀
able. It is alsopreferable if the input can be customized by the user.
However, because this is just a simple game, we have op 琀椀 mized the handling
of movement events in the game by touching the screen with your 昀椀 nger and
the game objects will move based on your wishes.
Example:( đợi Huy code xong giao diện)
Besides, we also op 琀椀 mize the UI as much as possible. Here is the image when
the game runs:(đợi Huy code xong r chụp ảnh) lOMoAR cPSD| 48704538 Coding Standards
Coding standards are a set of rules and conven 琀椀 ons that de 昀椀 ne how to
write and format your code. They help you to keep your code consistent,
readable, and organized. They also make it easier for other programmers to
understand and modify your code, which is especially important for collabora 琀
椀 ve projects. There are many coding standards but we have tried to stay as
close to C++ and objectoriented programming standards as possible. The rules we
have implemented can be detailed as follows:
Every comma is followed by a space, for example doStu 昀昀(5, 7, 8)
Spaces around operators, for example: 5 + 7 instead of 5+7
Tabs have the same size as four spaces. Tabs are stored as tabs, not as spaces.
Func 琀椀 ons and sta 琀椀 c variables are in the same order in the .h and .cpp 昀 椀 les.
Try to make short func 琀椀 ons, preferably no more than 50 lines.
Avoid making very large classes. Split a class whenever you an 琀椀 cipate the
class will grow a lot and you can cleanly split it. In general, try to keep class sizes below 750 lines. lOMoAR cPSD| 48704538
Don't write lines that are longer than what 昀椀 ts on a normal 1920*1080 screen.
Names of variables and func 琀椀 ons should be descrip 琀椀 ve. Long names are
no problem. Only use abbrevia 琀椀 ons if they are very clear and commonly known.
The 昀椀 rst le 琀琀 er of classes, structs and enum type names is a capital.
Variables and func 琀椀 ons start without a capital. Each further word in a name
starts with a cap 琀椀 cal. Don't use underscores ( _ ) in variable names.
Implementa 琀椀 ons of func 琀椀 ons are never in .h-昀椀 les.
Variables inside func 琀椀 ons are declared at the point where they are needed,
not all of them at the start of the func 琀椀 on.
Never ever even think of using go-to statements.
Use override and 昀椀 nal wherever applicable.
If a func 琀椀 on is virtual, the virtual keyword should always be added to it, so
not only in the parent class, but also in each version of the func 琀椀 on in the child classes. Development Tools lOMoAR cPSD| 48704538
Game dev tools are cri 琀椀 cal for suppor 琀椀 ng di 昀昀 erent stages of game
development. They help facilitate the crea 琀椀 on of character models,
gameplay physics, AI for non-playable characters (NPCs), icons, menus, sound e
昀昀 ects, help screens, bu 琀琀 ons, and even backend systems integral to game development.
With the rapid advancement of technology, every year a new wave of video game
development tools emerge to join the tried and tested tools all game developers
can’t live without. In recent years, that’s included tools that leverage AI to, not
only streamline the development process, but also push the boundaries of what's
possible in game crea 琀椀 on.
From assis 琀椀 ng in genera 琀椀 ng landscapes to building autonomous AI NPCs
players can talk to voice-to-voice, AI-powered tools are 昀椀 nding a place
alongside game developer tools that have been around for decades.
In this project, because it is a simple game with few features, we have chosen
some outstanding tools as follows: Abode Photoshop Visual Studio Github