3072 Sprites demo
Wuerfel_21
Posts: 5,054
In reference to some off-topic posts in another thread, here's a quick and dirty proof of concept of a fast sprite driver using the sorted list and bitmask method outlined there.
Draws 3072 16x16 sprites at 640x480 in 32bpp mode (using WMLONG-style transparency) using 4 cogs at 252 MHz (no crazy overclock! yet.). If you put too many sprites on the same line, you'll have a bad time (one could surely implement some sort of "stop rendering when out of time" logic).
Is this a silly amount yet @pik33 ? (For reference, the touhou game has an internal limit of 1024 enemy shots. I think the later ones go to 2000-something.)
Comments
That is. I have to look at the code. They are 16x16 fixed size? If yes, there is no need to compute width and height of the sprite that saves several clocks... my sprite loop uses something about 38 to 58 clocks when the sprite is not drawn and most of this time is used for retrieving the coordinates from longs (alts-getword-signx).
Maybe it is a good idea to implement something like "player-missile" graphics (Atari 8-bit name) where these big sprites with size that can be defined are "players" and these small fast ones are "missiles". In Atari 8 bit "player" was 8 pixels wide, "missile" was 2 pixels wide (and both can be full screen height there)
Yes, fixed 16x16. Though there's an unused type field that could be used to branch off to more complex handlers that would be used for rendering shrine maidens and similar delinquents. Though the pointer field would have to be used to point at an additional attribute object rather than at the pixel data directly. Of course there doesn't need to be pixel data, could also draw filled shapes like VJET/SpinHexagon.
Also, with my technique a sprite that isn't drawn takes basically zero cycles, its attributes are never loaded. ENCOD just skips over the unset bits, 32 at a time and that's that. Also, don't need no signx if you offset the coordinate space a bit. Also, clipping can be avoided/made easier by making the buffers slightly wider than the screen. Then you can just draw into that border and don't have to think about how many pixels you actually want to draw.
I had to do some work to avoid the sprite, that is on the edge of the screen, to appear on the other side. Making the line size wider was not a solution for a sprite that can be 512 pixels wide. Also, while the driver has a display list and every line can have its own address in the PSRAM, the sprites are drawn on a line that is cached in the hub. The driver works in a pipeline mode, there is a buffer for 4 lines in the hub, the current line is displayed by the streamer while the driver draws sprites on line+1 and the PSRAM driver is preloading line+2. Making the buffer line width larger = restarting the streamer every line instead of starting it once at the start of the frame for the 4-line loop
I tried to run the demo. Got a static picture with green-blue squares and a lot of objects on it, that don't move. Compiled with
Version 6.5.0-beta-v6.4.0-61-g2d7e2aa5 Compiled on: Sep 15 2023Edit: They move when the optimization switched off.
Where you got these sprites from? They are fancy
Restarting the streamer FIFO during HBlank doesn't really cost much... You have to spit out some sync commands, should be enough time inbetween to mess with the FIFO. And of course this border trick becomes quickly unfunny when you try to apply it to larger sprites. But if you have a scrolling tilemap, it's actually very helpful to always draw whole tiles, and for that the 16 pixel border also works.
Well, they should be moving. Not sure what would lead to a stable picture but no animation. Have to try building from my actual ZIP, maybe it's scuffed.
Oh yeah, it breaks when you build with optimizations and no debugger. Debugger on and optimization also works. Cool flexsplorp.
https://excamera.com/sphinx/gameduino/samples/sprites256/
It turns out the P2 is 12 times more powerful than custom FPGA hardware (which also only happens to run at an oddball 400x300)
The usual... https://github.com/totalspectrum/spin2cpp/pull/417
To be fair, eve2 can do >1000 sprites in 720p .
https://forums.parallax.com/discussion/173787/antares-api-for-eve-powered-lcd-displays
This looks to be cool though .
Would be great to not need a gpu chip to do stuff…
Rogloh implemented PSRAM lists in his driver that can help a lot there while using PSRAM. Tiles don't have to be drawn, they may be placed in PSRAM and then a proper PSRAM list has to be prepared for the line. My driver already supports this:
These are 2 independent PSRAM regions - nothing is overdrawn, PSRAM lists are used to preload proper fragments to the hub to display.
The driver was modified to mot go out of the loop while executing the list (so no other cogs are polled until the list ends). There was discussion about it, I think in the PSRAM driver topic, and I don't know if this change reaches the official driver's release.
The horizontal scrolling line in the p2play is also done with a display list. That is a "secondary framebuffer" made, 16 px high and wide as needed, then the full text is printed on it 2 times, then the vblank changes the start adderss of these 16 lines in the loop
2048 sprites at 1024x768
@pik33 I mean tile map as in background map from repeating tiles, like the olden computers had (and is still used in many PC games because it's easier to make)
like... gestures around a tile map
It really helps not having to render a partial tile, that just makes everything slow and sad
Yes, in the case where these tiles are small, define a framebuffer that is one tile wider and one tile higher is the best thing to do (and I can do it without changing this 1024px internal dricer's buffer, these are independent things.
In the case where tiles are bigger (8...maybe 16 per line) and it is a PSRAM system, nothing has to be drawn at all, only a PSRAM list has to be prepared to select proper tiles and their position on the fly As the processing of PSRAM lists entries cost some time, this can't be done this way where there are too many of these tiles per line.
I am still thinking about implementing this windows system, where up to 8 windows can produce up to something like 225 fragments on the screen. Define the window as a rectangle framebuffer in the PSRAM, then generate a PSRAM list to display them. As in the example above, but more than 1 window.
I tried to do a new very simple audio driver yesterday... Maybe the same thing. Debug on - sine wave OK, debug off, sine wave distorted... Unable to debug.
Works flawlessly up to something about 2500 sprites. At 2600 or more there are glitches on this red bar at the left. Used the new compiler and full optimization that now works.
Yep, though the way the gradient background is drawn is rather slow, so if you comment out the
'{ rep @.loop,##MAXWIDTH wrlong r_tmp0,r_tmp1 add r_tmp1,#4 add r_tmp0,#256 .loop '}section, you can actually get up to 3072 again. Though 4096 runs out of VBlank time. Will have to think about making the VBlank job faster (lots of potential here, currently only uses 1 cog)
Gameduino has one example using this stuff: https://www.kenney.nl/assets
For tiled background and things...
I think this is the level editor I found that looks good:
https://ogmo-editor-3.github.io/
After that is when I figured out that actually creating a new game is a LOT of work!
Hence, my exit...
Creating a game is exactly the same as creating any other program
. Idea->project->code->debug...
One of purposes of my Basic interpreter is make this process easier, as it now has tools to do a lot of things (not all I wanted however - yet) needed for a game programming. A simple breakout/Arkanoid type game demo, very simple but working, is less than 50 lines of code there and dowsn't load any files.
It all depends on your expectations. Coding a simple game like Tetris or Centipede can be done in a single day by an experienced programmer and still be fun. However, todays state of the art games show hundreds of programmers, musicians, artists and support staff in the end credits. It's produced like a hollywood movie and requires multi million $ budget. You simply can't compete with that.
Not on a P2 or anything small like this. These games are interactive movies. They needs gigabytes of RAM, terabytes of storage and teraflops of computing power. And all of this is not needed at all to have a playable game and have fun with it.
The hard part of making a game to me is actually just coming up with good ideas. The programming, music, gfx, etc are all easy to make if you know what you want. The Projekt Menetekel, uh, project, is currently stalling due to acute slowness of coming up with good ideas for what to put in the actual maps. Need to make a big push on that again.
I wanna say writing Spin Hexagon (which of course has zero ideas, being a 1:1 clone of an existing game... unless you count the polygon scanline renderer as an idea, but I wouldn't, it's just a means to an end) took the better part of a month, but that included making the video/audio drivers from scratch and severe fighting against flexspin and the P1's 32K limit. (Also I think I rewrote the main logic multiple times before ending up with the current bitmap-esque method that allows sharing vertex transforms between adjacent walls)
I think if you can come up with something that is very fun and addicting to play, there is no need for all the fancy graphics and music. People will like it just because it challenges them and maybe makes them laugh.
It seems to me that playability has been trailing way behind graphics and sound, since the 1990's. There are some yet-undiscovered game concepts that could be realized on simple hardware that would smoke the entertainment factor of today's games, but what are they?
I was thinking maybe AI could help with game graphics and maybe other things. Tried a little with Arta, but doesn't look promising... Maybe should ask ChatGPT for game ideas...
BTW: I like the idea behind "Bloxels". Was thinking this could be hosted and run on P2. Still, even this is a lot of work...
https://edu.bloxelsbuilder.com/
Original version had this kind of clever way to design and input graphical elements (input using app on phone):
I brought up Touhou in the post that spawned this thread as an example of, uh, reasonable and good amounts of sprites you need to render (here's that link from earlier again), but it's a good example of this as well, it turns out. Simple game, made by one guy, where funny characters say funny words and you laugh. And then you die because the boss fight is really difficult, but then you start over because it's actually fairly designed and does not make you want to throw the game into ocean (many other shooter games can take notice). Does basically hinge on having really nice music though
Then again, most of ye olden games had great music, too. I guess it's important to note the sort of "free culture" approach where people are allowed to make and possibly sell their own touhou-based stuff as long as they're not ripping any actual data. It wouldn't be as popular without that, certainly not.
Other funny(?) and difficult one that I played semi-recently and can possibly recommend is Celeste. That one was actually prototyped on Pico-8 (very basic and intentionally limited programming environment based on Lua - wonder if a P2 could run it?) and turned into a full PC game later on. Expansion levels are obnoxious though and made me stop playing
may need to try again. Funny one that certainly doesn't run on a P2 is called Teardown, which uses a novel voxel engine to do fully destructible environments (with some fancy software raytraced lighting even!), wherein you then have to perform some quite illegal acts without getting caught (or, in some later levels, getting shot by the omnipotent attack helicopter)
I think there's still sufficient creativity in small PC productions. But most of them are very simple (but extensively well-tuned) ideas that would work with, and in many cases, actually are using low-rent 2D graphics.
The arguably greatest tragedy in gaming (aside from shitty money-grab tactics. see: any phone game. they're all intentionally awful to make you pay money to skip parts of the game. bonus points if they have an "auto play" button, the hallmark of a game designer just giving up) is the tendency towards fake progression in empty open worlds. You always level up and get new weapons, but the enemies just level scale so nothing actually changes. Ever play the new Zelda games? (really, BotW, haven't played ToTK yet) I sure love how as you play, eventually all the regular ass bokblins that spawn in their hundred identical camps across the wilderness become the overbred silver version and have high-end gear that can take out 10 hearts in one hit. Totally cool in a game where the main gameplay feature (solving 120 copy-pasted shrines*) rewards you either with more health (useless because the enemies just get stronger) or more stamina (useful primarily for holding "up" and watching link run or climb for 5 minutes (bonus points if it starts to rain while climbing and you fall all the way down)). (* To be fair, some of the shrines have the challenge on the outside and are far more interesting for it. Though I guess this balances out with the ones that are literally the same miniboss battle repeated with very slight variation)
I feel like this open-world-i-fication sort of comes from a point of looking at the level boundaries you'd have in older games and wondering "what's over that hill?". That question and wonder itself is arguably far more interesting than anything a game designer could actually put there (on the assumption that every new location actually recursively creates even more such level boundaries). And so one ends up with empty nothingness littered with the same handful of assets repeated ad nauseam, for that's all we can afford to put there, even with massively inflated budgets. The other prong sortof comes from people thinking that levels in a fixed (or at least somewhat restricted or guided) order are in some way "outdated" or otherwise lesser, when really, that's the only structure that can really lead to a coherent flow where later content builds on concepts introduced earlier and everything follows a proper increasing difficulty curve. Without that you also can't introduce any required abilities mid-game, which either leads to frontloading every game mechanic or making every problem solvable with just the basic abilities (so new ones are either useless or worse, trivialize the problem -> inverted difficulty curve! ah!). Then again, maybe I'm just malding about the Zelders again (actually, looking at the size of these paragraphs... and I haven't even talked about the "ludonarrative" at all), I think the brunt of this particular sillyness may have passed and more linearly structured games are popular again.
No. Just no. As mentioned, graphics are one of the easy parts, esp. if you stick with a simple pixel style (which you kinda need to on propeller-tier shitboxes for technical reasons, anyways). I guess you could get a vague idea/direction out of GPT, but actually implementing it properly is something you need to do all yourself. Though more likely you just get stuff that's already been done a lot or just bad ideas. Not that making a really good version of something that's been done before is bad, but you don't need a computer to tell you how to do that.
Looks like they've rationalized the 2D-scroller-game genre down to EIGHT basic elements, so that new games can be created without any programming. That's quite a commentary on those types of games.
Your thoughts on all these game types are interesting, Wuerfel_21. I don't know enough to even think clearly about them.
I remember back in ~2003, a friend and I would wait for each new version of Halo for XBox to come out and then we'd stay up, playing all the way through it, eventually getting through the whole game in "legendary" mode. When we bought Halo 3, we were all excited to have a new game to play, so we started playing through the levels. We only got to maybe the second level of the game and I had this heavy sense of deja vu. I was on the edge of my seat, hardly breathing, a bit nauseous, and very tense. I realized that this was just the same formula, over and over and over, and at that moment, I just quit, having lost ALL interest in the game. I have never played such a game, since. Once the repetitiveness of the formula snapped to grid, it was suddenly the most boring thing, ever, and I was totally done with it. No amount of new graphics and content could overcome the staid formula that it was all based on. It kind of ruined gaming, for me.
You could possibly make that argument for all 3D FPSs released since the Doom/Quake era when they first hit their strides. But I'd have to admit it is pretty hard to invent new game genres. In some ways the 2d arcade games from 80's are still really good, given their variety and despite the simplicity. I quite like games you can figure out quickly and can just jump in and play when you have a spare moment. After my student life I just don't have the time to invest hours at a time playing a modern game that appears as a pre-rendered movie in many places and you have to just passively watch it. Although I did quite like that God Of War game on PS3.
I bet there are some game concepts that would blow away what exists today and wouldn't even need fancy graphics or sound. I know that I get all limited by what I'm already familiar with. Pretty much everything today can be reduced to touch screen interactions. There's got to be a lot possible outside of what a smart phone can present.