| Pages:
1
2
3 |
MikeDX
|
|
This is so so cool.
I wish the web version was a bit more optimised though 
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Can anything be done to improve that?
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
OK it's not completely simplified. I have an orbitting camera to show off.
|
|
|
MikeDX
|
|
well, the resolution causes problems as div was never really meant to run at such high res. it draws ever pixel every frame, so we would have to
employ such practices as dirty rectangles.
the switch to sdl2 properly would fix it, as each graph would become a gpu poly.
just a lot of work, and not something I'm overly familiar with.
640x480 was always about my limit!
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Not familiar with dirty rectangles. GPU polies sound cool though.
The black chunk on the right (width 400 pixels) is only there for debugging purposes so the intended final resolution is more like 1000x800 or to be
more conventional maybe 1024x768 which DIV did support. So maybe getting rid of that will help a bit. I'll upload a truncated version.
Just noticed that holding down F1 boosts the fps. Why might that be?
[Edited on 2-6-2019 by dom cook]
[Edited on 2-6-2019 by dom cook]
|
|
|
CicTec
DIV Pro
Posts: 471
Registered: 6-8-2016
Member Is Offline
|
|
dirty rectangles is simply a rendering technique to improve the performance of the FPS in which, instead of constantly updating the screen entirely,
the program keeping track (or not keeping track depending on the technique) of the graphs and their positions, updates only portions of the screen (or
does not update).
This technique is embedded in DIV in the variables you know as dump_type and restore_type.
the first deals with a partial restoration (partial_dump) of the graphs (so it only updates the zones where in the next frame there will be a visual
change from the previous one), while the second takes care of the bottom of the screen.
To understand how it works, you have to imagine the screen resolution as a sheet of paper, the bigger the sheet, the more things you can draw on it
(like the resolution).
Now imagine having a small sheet, at the top left draw a triangle, at the top right a circle, at the bottom center a rectangle.
Now imagine having to replace the triangle at the top (so an update of the drawing, like a following frame) with a traprezio, what do you do? Well,
just take the gum, delete the triangle (so the portion of the sheet where it is drawn) and draw the trapezoid in its place ...
The rendering doesn't work like that, in complete_dump, it takes the whole sheet, deletes everything, draws the new trapezoid and redraws the circle
and the rectangle.
At this point you think, but lose more time in this way, and you are right, in fact, using partial_dump, do what you would do with the sheet, take
only the area of the triangle, delete it and draw the new trapezoid, saving time (gain of FPS).
The problem with this technique, which has been abandoned over the years, is the one that works well when there are few areas to update (or few
objects) but bad when the areas become too many, because it has to keep all the areas in order and delete them at one by one (and the iterative cycles
are expensive) or worse still have to calculate any areas close to each other to merge a larger one (to have less areas to iterate), all calculations
that eventually make it slower in terms of FPS than to erase the entire screen directly.
Quote: Originally posted by dom cook  |
GPU polies sound cool though.
The black chunk on the right (width 400 pixels) is only there for debugging purposes so the intended final resolution is more like 1000x800 or to be
more conventional maybe 1024x768 which DIV did support. So maybe getting rid of that will help a bit. I'll upload a truncated version.
Just noticed that holding down F1 boosts the fps. Why might that be?
[Edited on 2-6-2019 by dom cook]
[Edited on 2-6-2019 by dom cook] |
DIV is a game engine developed in the late 90s, where the predominant operating system was still MS-DOS and where the main PC models were 386 and 486
(pentium distribution was just starting), so it was designed , first for low-resolution games (given the limited power of the machines at that time),
then the use of graphic acceleration did not exist in MS-DOS, all the rendering was done by the CPU so the games that developed were mainly VGA
(320x200) someone up to SVGA (640x480), already a 800x600 resolution was a luxury, whether the graphics card and monitor supported this resolution, or
whether the CPU could efficiently support all this computational load.
Today developing a graphics engine for the GPU has become the standard solution, the problem is that it works completely differently from developing a
software engine like DIV, for example the technique of dirty rectancles is no longer used today, as explained, needs to trace information and iterate
through them, modern rendering happens with the GPU through little information that is passed to them and the writing of small programs called
shaders, which are written in a special language to be executed by the GPU, these programs have a support for conditional statements (such as IF) and
iterations (like FOR) that are very low or absent, so it is not possible to implement such techniques in a GPU rendering, in addition to the
performance defect indicated above.
In any case we always return to the starting problem, the GPU works by its nature in floating point and other features and the current DIV core does
not support any of this.
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
So, what's the plan? Is anything happening about this?
As far as I can gather DIV development is esentially comatose and the prospects of a recovery don't seem too bright.
I'm not holding out much hope for DIV's future. But, hey, it still does what it does and is fun to play with and as long as it can do what I want it
to do, I'm basically happy.
|
|
|
CicTec
DIV Pro
Posts: 471
Registered: 6-8-2016
Member Is Offline
|
|
| Quote: Originally posted by dom cook | So, what's the plan? Is anything happening about this?
As far as I can gather DIV development is esentially comatose and the prospects of a recovery don't seem too bright.
I'm not holding out much hope for DIV's future.
|
As I have indicated several times, everything starts from the necessary complete rewriting of the core, once this contains what the 21st century
requires for the development of a game engine, you can think of being able to add what you want, but what a development plan have in mind Mike for the
project seems to be unclear.
| Quote: Originally posted by dom cook |
But, hey, it still does what it does and is fun to play with and as long as it can do what I want it to do, I'm basically happy.
|
This is already important.
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
I've made a few additions and improvements so I figured it was time for another update/ backup.
My favourite new feature is the vortices that open up when the thieving 619905 break into the arena.
Attachment: ripoff604.PRG (71kB)
This file has been downloaded 825 times
I'm actually starting to enjoy this project now.
I'm not sure if these files have been updated but just in case, here they are.
Attachment: FONT0.FPG (20kB)
This file has been downloaded 827 times
Attachment: RO.FPG (252kB)
This file has been downloaded 797 times
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Particle explosions
The particle setup I used for the vortices is easy to modify so I'm modifying it it for the explosions.
 
Of course, these are much cooler IRL.
Each player gets his own personal (colour-coded) explosion style.
[Edited on 4-6-2019 by dom cook]
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Upon Reflection
In my opinion, for the first generation of video/arcade games to succesfully attract players some sort of plot was esential, These plots were, by
necessity, simple. Think about Space Invaders or Asteroids and just compare what happens on screen with what the images are supposed to represent to
understand how much of a part the imagination plays in making games playable.
Anyway, the plot of Rip-Off is as good an example of this as any. Space pirates stealing invaluable energy crystals or whatever. But, without some
elaboration, the gameplay and the plot don't gel properly and that can cause some cognative dissonance which then leads to the spell being broken and
the game not working. For example, How come you can respawn an infinite number of times? How can the pirates leave and enter the game area while the
player's tanks will warp/wrap around to the opposite side? We could just remove the wraparound feature and imagine that the action is occuring in
some sort of clearing or yard, but the warping is a big factor in terms of game play and removing it negatively affects the playability. besides, it
can be a fun exercise to try to address such inconsistencies and originate a plot (however silly) that makes sense of them.
So, in this case, I imagine this conflict taking place in a subspace bubble, created as a hideout/stronghold for the storage of the valuable crystals.
The pirates have found a way to break into this bubble, hence their ability to enter and leave the screen. The players, however, are locked in.
They experience the screen as a nano-universe of sorts which they wrap around akin to being on a tiny planet.
Having adopted this notion, the next step is to represent it visually in the game. For this exercise I'm attempting this by adding some effects for
when the objects interact with the boundary. As mentioned earlier I have a vortex, which is a classic way of representing a portal. This is for the
pirates entering and exiting. The players, however, need something else, something which shows the containing effect the walls have on them while
still allowing them to warp to the other side. For this I'm using reflctions. As they player's tank approaches the wall its reflection appears and
increases in brightness as it gets closer. upon contact a strange telportoisis occurs.
Attachment: ripoff607.PRG (88kB)
This file has been downloaded 853 times
If you download this and want to try the wraporound feature you need to turn it on. Keys 1 and 2 turn it on and off, I'm not sure which is which.
[Edited on 7-6-2019 by dom cook]
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
As is usually the case when impulsively adding "cool" ideas, this reflection effect has turned out to be a little more work than expected. Confining
the reflected image to the mirror required a bit of vector magic, including the line intersection code I thankfully (because I don't remember how to
write it)
posted here a few years back.
In these images the reflections are confined by the upper edge of the mirror.
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Finished reflections and added a few effects here and there.
So far so good.
Attachment: ripoff616d.PRG (93kB)
This file has been downloaded 818 times
[Edited on 16-6-2019 by dom cook]
|
|
|
dom cook
Div Pro
Posts: 387
Registered: 4-3-2016
Member Is Offline
|
|
Been working on the menu. This wrapping always takes way more code than it seems to be worth but a game is incomplete without it.
Most the work has gone into the demonstration which animates certain major aspects of the game.
Attachment: ripoff627c.PRG (127kB)
This file has been downloaded 785 times
..and have a good summer.
|
|
|
| Pages:
1
2
3 |
![[*]](images/davis/default_icon.gif){kind=icon}
