|
|
Post by dragonjim on May 11, 2023 15:19:29 GMT 1
Why not start a library based project to which people can contribute. I'm sure between all of us, we could come up with very good sprite generating code...
|
|
|
|
Post by larrybtoys on May 12, 2023 10:56:20 GMT 1
I am in it for fun however I would gladly pay for a Sprite add-on kit of some sort. Back in the 80's when I was programming on the C64 I was able to do a lot more using sprites. With the awesome power and speed of GB32 Sprites would allow for some amazing stuff.
|
|
|
|
Post by larrybtoys on May 12, 2023 12:59:27 GMT 1
I'm convinced. The above is great and I think would interest many would-be game programmers.
|
|
|
|
Post by Roger Cabo on May 13, 2023 17:25:06 GMT 1
I'm convinced. The above is great and I think would interest many would-be game programmers. The bit blt is extremely slow, if you compare to D2D.. the handling is the same.. And the "how to" structure is also the same. Global SHwnd%(0) Dim handle% = @spliteload("abc", SHwnd%()) MsgBox SHwnd%(handle%) Do FlipScreen(screen%) CLS @spritesdraw() ...
Loop until anything @splitesrelease() Proc SpritesDrawGroup() SpritesDraw(SHandle%, x#,y#, Mod%) ....
Scalion wrote some games in D2D with sprites. If you use put, d2d or blit behind the code it doesn't matter.
A lib is nothing else then storing one spite inside of an array or delete at any time. Then grab it by an ID%.
Is there anything special you need? Like alpha-blending or masking? then I would prefer D2D or the old GDI.
|
|
|
|
Post by (X) on May 15, 2023 14:49:02 GMT 1
I'd be willing to give it a good go, if for no other reason than to have something to point to when someone asks:
"Why have you been spending all that time on your computer?"
Answer:
"Well, here's a program that I worked on with others that lets anyone create a game in minutes."
The name of the program would depend on the purpose and features of the program.
Here are a few possible names that could incorporate GFA-BASIC 32 for Windows: "Create games in minutes, not days!"
Obviously, it would also be great to point to a practical application that helps people. Nothing wrong with that.
|
|
|
|
Post by Roger Cabo on May 15, 2023 16:00:52 GMT 1
If you're starting with a library, there are a few issues you should consider: A) What is your intention? Do you want to showcase your game to the world and let them play it? B) Is your game designed to be compatible with different screen sizes such as 1980x1080, 2540x1020, 800x600, 1440x900, 4K, or anything in between or beyond? C) If you're not concerned about dynamic screen resolutions, then you can handle everything on your own. D) Do you want to make money with your game? Are you serious about using GFABASIC32 in this case? E) It's pure just for fun? I would also like to write a game in GB32, something similar to Out Run or Atomix. I have even developed Atomix completely for the Atari. I have always been fascinated by how they created the road in Out Run, with all the ups and downs as well. These games are all implemented in 2D using sprites. Outrun : www.youtube.com/watch?v=ELUl-cAtUIEAtomix : www.youtube.com/watch?v=eGWs22WLSMU |
|
|
|
Post by (X) on May 15, 2023 16:10:47 GMT 1
I am into coding for fun. Perhaps a little for "educational purposes". I am definitely NOT in it for money of profit.
Though, if someone offered me a million dollars for a program I wrote then...
Click on the image for an animation of a total freak out!
|
|
|
|
Post by Roger Cabo on May 15, 2023 17:08:39 GMT 1
It's okay, why not! :-)
To have some fun I would like to have the lib in D2D. Otherwise the speed became terrible.
My suggestion would be to the following functions:
Base Function:
D2D_Sprites_CreateStage(count%,x%,y%,w%,h%) // does create N flip screen memories.. 1 to 10?
D2D_Sprites_ReleaseDB()
_________
Id%= D2D_Sprites_AddSpriteToLib("file.bmp", Mode=alpha blending/alpha masking, "mask.bmp 8bit/24bit /*results in 24 anyway in memory */.", Resize_on_Load= 0 to 5000%, IsCollider = True/False)
When a sprite is moving at a high speed per frame, the standard collision detection methods might not be sufficient. In such cases, it is necessary to precalculate the collision detection to ensure accurate results. Precalculating collision detection involves predicting the potential collision points or areas based on the sprite's velocity and position in each frame.
By performing this precalculation, you can anticipate and handle collisions accurately, even when a sprite is moving rapidly. This approach helps avoid situations where fast-moving sprites might pass through or overlap with other objects without triggering a collision event.
Overall, when dealing with fast-moving sprites, precalculating collision detection is crucial to ensure the game's mechanics and interactions are reliable and realistic.
_________
Id%= D2D_Sprites_AddColliderStageToLib("mask.bmp" always BW, Resize_on_Load= 0 to 5000%) // that's important but ugly.. to code..
Id%= D2D_Sprites_RemoveSpriteFromLib(ID%) // return success
Lib Functions:
D2D_Sprites_ExistID%(id%) // true or false
D2D_Sprites_GetSize(id%, byref x#, byref y#)
D2D_Sprites_Resize(id%, to new x#, to new y#)
D2D_Sprites_GetDBSize() // return memory consumption of all sprites and database
D2D_Sprites_GetLastSpriteSyncTime() // returns how many 0.000ms are gone between the last drawn sprite and the next Vsync. Important to calculate what time overhead if free to draw additional sprites.
D2D_Sprites_ScaleStage(+/- multiplier%) // after drawing all sprites you can consider to enlarge the complete stage by a multiplier
D2D_Sprites_PositionStage(x%,y%) // set position of the stage
Collider Functions:
D2D_Sprites_HasCollision(id%, id%, rectangular/cyclic, x#, y#, c#) // true false
D2D_Sprites_SetColliderStatus(id%, true/false) // Enable/disable
Draw Functions:
D2D_Sprites_Draw(id%,x#,y#)
D2D_Sprites_FlipScreenTo(ScreenID%)
D2D_Sprites_ClearScreen(Id%)
Could be the basics of a lib.
|
|
|
|
Post by (X) on May 15, 2023 17:21:13 GMT 1
D2D, D3D whatever... The Faster the Better!
I am using sprite in very broad terms, more like an element of an environment that can be assigned properties.
I imagine running the program and doing a few drag 'n drops and only having to answer a few questions:
What is this sprite's name? How big do you want it to be? or percent of screen width or height? Is it part of another sprite? (Like a dial on an instrument panel or a wheel on a car)
Can it move? How? Pitch, Yaw, Roll, Flip, Spin?
If so, what action/key triggers the directions? up? down? left? right?
What happens if a sprite called "ball" collides with another sprite called: "wall"? () bounces off, () crashes, () catches fire?
|
|
|
|
Post by Roger Cabo on May 15, 2023 21:36:02 GMT 1
D2D, D3D whatever... The Faster the Better!
I am using sprite in very broad terms, more like an element of an environment that can be assigned properties.
I imagine running the program and doing a few drag 'n drops and only having to answer a few questions:
What is this sprite's name? How big do you want it to be? or percent of screen width or height? Is it part of another sprite? (Like a dial on an instrument panel or a wheel on a car)
Can it move? How? Pitch, Yaw, Roll, Flip, Spin?
If so, what action/key triggers the directions? up? down? left? right?
What happens if a sprite called "ball" collides with another sprite called: "wall"? () bounces off, () crashes, () catches fire? Some ideas: * What is this sprite's name? Perhaps use a hash table with int as sprite id% * How big do you want it to be? To get the 80/90 flare each original pixel is multiplied by 4 until 8.. generally you should target your game to 16:9 then multiply the finished screen to any value you like. For sure it possible to build a defender game in 4K. D2D its fast enough these days. * Is it part of another sprite? (Like a dial on an instrument panel or a wheel on a car) You can create a sprite container: This is a lot ugly work. id% = D2D_Sprites_NewSpriteContainer() D2D_Sprites_ContainerAddSprite(containerID%, id%, x#, y#) D2D_Sprites_ContainerSetCenterPosition(containerID%, x#, y#) D2D_Sprites_ContainerDraw(containerID%, x#,y#) Now you should write some compute shader in D2D to rotate , strech, scale.. etc.. the container withing alle the single objects.. * Can it move? This should do the programmer by it's own. If you have a game like side winder, or "shoot em up" Galaga developer create splines where the sprite move a long. This is an extremely complex programming behavior if you want to integrate this onto you lib for several reason. If the developer doesn't care by itself there no real way to check collisions. what happen if the developer say use spline "x" then jump after 5 seconds pixel to spline "Y" then move 20 pixel from position A to position B, then if a collision happen jump to spline "AS19" and move along for the next 10 node it gets hit. * Pitch, Yaw, Roll, Flip, Spin? This could be a simple command.. like D2D_Sprite_Yaw_Roll_Flip_Spin("what-to-do", value). and must be called each frame simply. Now you should write some compute shader in D2D to rotate , strech, scale.. etc.. or D2D can do for you.. www.youtube.com/watch?v=Y00gtHqE0UU
* If so, what action/key triggers the directions? up? down? left? right?
USB Joystick, keyboard, mouse * What happens if a sprite called "ball" collides with another sprite called: "wall"? () bounces off, () crashes, () catches fire? A) There for you should use a sprite collider, this is a simple sprite has a collider a bounding box or cyclic collider.. (totally simple). I have a box intersection code that checks 100.000 collisions in one second on a mid speed PC. B) As I wrote, load a stage collider mask each time any of the a "collider sprite" hits the "collider mask" or other "collider sprite" by D2D_Sprites_HasCollision(id%,id%) you return true of false. and the developer must react on. But what you can do is to animate sprites in the lib code.. id% = D2D_Sprites_LoadAnimatedSprite("file", count%, speed%, mode%) how ever the stuff should work. D2D_Sprites_AnimatedTime(Id%, ms% or frames%) // 0 = off > 0 step per frames Or you can use Sprite Gamemaker 2D where ppl spend 10 years to develop a great lib with 10 ppl. .. Here you can see how complex all this tasks are.. www.youtube.com/watch?v=rUN7e-UFbSk&tIn the end hard work for the developer :-) |
|
|
|
Post by (X) on May 15, 2023 21:57:40 GMT 1
Those games are what we should be able to build in minutes.
In other words, there would be many "default" settings.
|
|
|
|
Post by Roger Cabo on May 15, 2023 22:33:16 GMT 1
Those games are what we should be able to build in minutes. In other words, there would be many "default" settings. If you like to create a gamemaker lib for GB32, so ppl can develop a game like Galaga in 10 minutes, then you need 2 years to develop a gamemaker lib for GB32. If you like to create a gamemaker lib for GB32 in 10 minutes, then ppl need 2 years to create a game like Galaga. What is your goal for gb32 in case of the sprite lib?
and what functions you like to implement?
|
|
|
|
Post by larrybtoys on May 15, 2023 22:50:38 GMT 1
Some of the same functions that the Commodore 64 had with regards to sprites. It has been a long time since I had a C64 but I remember sprites being pretty great. Functions like:
> Moveable without disturbing the background
> Priorities
> Collision detection (sprite to sprite, sprite to object, etc)
> Multi-Color
> Enable / Disable
> Sprite hotspot
> Different (sizes would be nice but if they were all one size I could live with it-40 x 40 or 60 x 60)
> Scalable (would be nice also but not required)
Are some that come to mind. I have several games tabled due to needing sprites.
|
|
|
|
Post by (X) on May 15, 2023 22:51:18 GMT 1
With the help of other programmers and surely AI, I would like to develop a Sprite Lib as quickly as possible with the ultimate goal of making it very easy to develop a game or a simulation in minutes, which means: a noob can take an idea and turn it into a functional proof of concept in under an hour. I know it's not a weekend project, I can well imagine it never really being complete in every way. I would just like to have a collaboration project that I could point to as a tangible result of a group's many years of experimentation and learning about programming.
It might not necessarily be this particular project, but perhaps some other collaboration that could serve as a prime example of what can be achieved when creativity and hard work are given free rein.
|
|
|
|
Post by Roger Cabo on May 15, 2023 23:48:15 GMT 1
Some of the same functions that the Commodore 64 had with regards to sprites. It has been a long time since I had a C64 but I remember sprites being pretty great. Functions like: > Moveable without disturbing the background > Priorities > Collision detection (sprite to sprite, sprite to object, etc) > Multi-Color > Enable / Disable > Sprite hotspot > Different (sizes would be nice but if they were all one size I could live with it-40 x 40 or 60 x 60) > Scalable (would be nice also but not required) Are some that come to mind. I have several games tabled due to needing sprites. * Moveable without disturbing the background. They are implemented as hardware, not into the ram. That doesn't work today like 1980. Believe me, if you like to start to restore the screen where a sprite was drawn, you will ran into unsolvable problems! Impossible!! Flip screens are the only solution today and it's fast enough.  and you can do exactly the same. * Priorities, Ah okay.. as I know sprites are implemented into the hardware as overlay. They was not a part of the text or graphic using colors for priorities. Today you can draw a Sprite by Priority to give it a Number from +10000 to -10000. * Collision detection, is simple.. tell any sprite to collide could be simply by add a INT flag also from 0 to 1000.. means sprites with a flag eg. 586 in it's group produce collisions with each other. Sometimes you don't want to receive a collision with player fire and the player itself, but with the enemies. * Multi-Color, I think a GB32 sprite lib should use more than 16 colors... or? * Enable / Disable, that should work easily * Different sizes, you can use sprites with 1 pixel or larger than the screen today. * Scalable, also a simple task.. Could it possible you want to build the Commodore 64 sprite system exactly? Note: There is on thing you should keep in mind, in the past we use cathode TVs or CRT monitors, today we use LED Screens. Sprites on a CRT or cathode system looks totally great, because they are slightly frame blurred. This blurring behavior is not equivalent to a blur mechanism on a LED screen. Further the responsibility is 0ms on a CRT. |
|
|
|
Post by larrybtoys on May 16, 2023 2:10:15 GMT 1
I do agree that CRT's did have some pretty cool look. That's just something we need to live without. I would have to dig out my old C64 programming guide and read up on all the functions of the Sprites but back in the day I do remember them being pretty useful.
|
|
|
|
Post by (X) on May 16, 2023 2:39:59 GMT 1
In grade 10, I looked longingly at the Commodore PET computer at school and was teased when I found out the next door neighbour had just bought one. I soooo wished I could test it out, to see its limits, to do anything really. 2 years later I got my own C64, cassette drive and printer for ~1200$. The salesman said:" You'll be writing your own games in no time!" I believed him because I thought:"Yes. How hard can it be? As long as you know what you are doing." It's the 'know what you are doing' that's the catch. If I could talk to myself back then I'd have said:"Find a mentor! Find a mentor! Find a mentor!" Search far and wide and "Find a mentor!" Don't stop looking for the best mentor you can find. Through the years, I found Big Foot, a few Unicorns but never found anyone that had the passion for programming that I had until I stumbled onto the GFA websites. I could see there were coding enthousiasts like me all over the world. Well here I am banging away at the keys and making magic happen. Couldn't be happier in terms of fulfilling a dream.
|
|
|
|
Post by dragonjim on May 16, 2023 12:03:30 GMT 1
The STOS program on the old Atari ST may be a good template to work from. It was the go to game creation program on that platform.
|
|
|
|
Post by Roger Cabo on May 16, 2023 20:06:11 GMT 1
|
|
|
|
Post by larrybtoys on May 17, 2023 2:03:04 GMT 1
The Sprite package doesn't need to be all powerful off the bat. Perhaps just the basic features to begin with such as:
> Multi-Color 32 or 64 pixel box with a transparent color
> Up to 10 sprites at a time
> Sprite to Sprite collision detection
> Sprite to color detection
> The number of the Sprite is the priority
> Enable or Disable each Sprite
Just a thought
|
|
|
|
Post by dragonjim on May 18, 2023 16:57:28 GMT 1
Any implementation would require acknowledgement of the dimensions of the screen on which is displayed. You could use the stretch functionality in GDI, GDI+ and D2D or you could adapt the area around the main playing screen to expand or shrink accordingly to keep the integrity of the sprite.
I know that it is possible to adjust the screen dimensions but do not think is possible to do from a library (I'll be glad to be proved wrong).
|
|
|
|
Post by (X) on May 20, 2023 1:26:07 GMT 1
Here is my effort to change the current display w,h or size and back using a GFA-BASIC 32 for Windows Library: Lib_Display_Settings.LG32. (You will need to compile the library file and put it in the same dir as the program or in your lib dir.)
The code, as is, will change the current display to 800,600 resolution and restore to initial values at the click of the specified buttons. You can always change the settings in windows display settings if something goes wrong.
This is all made possible using USER32.DLL APIs.
Declare Function EnumDisplayDevices Lib "user32" Alias "EnumDisplayDevicesA" ( _
ByVal lpDevice As String, _
ByVal iDevNum As Long, _
ByRef lpDisplayDevice As DISPLAY_DEVICE, _
ByVal dwFlags As Long) As Boolean
Declare Function EnumDisplaySettings Lib "user32" Alias "EnumDisplaySettingsA" ( _
ByVal lpszDeviceName As String, _
ByVal iModeNum As Long, _
ByRef lpDM As Any) As Boolean
Declare Function ChangeDisplaySettings Lib "user32" Alias "ChangeDisplaySettingsA" ( _
ByVal lpDevMode As Long, _
ByVal dwFlags As Long) As Long
There may be even more use to these functions since they provide quite a lot more information.
|
|
|
|
Post by Roger Cabo on May 20, 2023 13:05:47 GMT 1
Some thoughts..
What do you think about making the game WinRT_1 bigger and displaying it on a second screen, WinRT_2? We can create an old-style game in 640x480 resolution and then make it fit the larger 1280x960 resolution of WinRT_2. We'll only show WinRT_2, which will look blocky but fit on an HD screen.
Switching between laptop and desktop resolutions can be messy. For example, on Windows, if there's a code error and GB32 terminates, it rearranges all the desktop icons on lower resolutions. It's frustrating when the desktop resolution stays at 800x600 and the icons don't go back to their original positions. Have you experienced this issue?
Instead of doubling the resolution to fit any screen, we could try scaling it by 1.5. That might help avoid some visual problems. Most desktops have a resolution of 1920x1080, while laptops have around 60 different resolutions ranging from 800 to 4K.
What are your thoughts on this?
Note: 3D games are not relevant in this context.
|
|
|
|
Post by (X) on May 20, 2023 13:15:10 GMT 1
Ya. Sounds like it's worth a shot to avoid changing the display settings.
There are definitely possible 'deal breaking' disadvantages when a program or user changes the resolution of a display. (like you said, it may rearranges the icons and perhaps other side effects that a user would not like/appreciate)
|
|
|
|
Post by dragonjim on May 20, 2023 21:33:03 GMT 1
Both options should be open to the programmer with the warning about abnormal termination leaving screens with incorrect resolutions if altered programmatically. If you're looking to stretch sprites, it is usually better to have larger sprites and make them smaller (so a 128 x 128 sprite fitting into a 96 x 96 space) rather than the other way round as both GDI+ and D2D handle that transition well and mitigate the blockiness (if that is a word). At the end of the day, we are looking to provide a platform for others, as well as ourselves, to quickly build games, so the more options available to the programmer, the better (within reason). P.S. Thank you (X) for proving me wrong |
|
|
|
Post by (X) on May 21, 2023 14:03:54 GMT 1
No problem. A bit of ChatGPT this and ChatGPT that and I was amazed that it worked at all.
This is definitely one of the tricks that a programmer should have up his sleeve.
Remember, to the layman, coders are magicians!
|
|
|
|
Post by (X) on May 21, 2023 16:10:06 GMT 1
I am looking into saving and restoring the original desktop icon placement.
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function FindWindowEx Lib "user32" Alias "FindWindowExA" (ByVal hWnd1 As Long, ByVal hWnd2 As Long, ByVal lpsz1 As String, ByVal lpsz2 As String) As Long
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Const LVM_FIRST = &H1000
Const LVM_SETITEMPOSITION = (LVM_FIRST + 15)
Sub MoveDesktopIcon(ByVal nIndex As Long, ByVal x As Long, ByVal y As Long)
Dim hwndDesktop As Long
hwndDesktop = GetDesktopListViewHandle()
Call SendMessage(hwndDesktop, LVM_SETITEMPOSITION, nIndex, MakeLong(x, y))
End Sub
Function GetDesktopListViewHandle() As Long
Dim hwndProgMan As Long
Dim hwndShellDll_DefView As Long
Dim hwndSysListView32 As Long
hwndProgMan = FindWindow("Progman", vbNullString)
hwndShellDll_DefView = FindWindowEx(hwndProgMan, 0&, "SHELLDLL_DefView", vbNullString)
hwndSysListView32 = FindWindowEx(hwndShellDll_DefView, 0&, "SysListView32", "FolderView")
GetDesktopListViewHandle = hwndSysListView32
End Function
Function MakeLong(ByVal nLoWord As Integer, ByVal nHiWord As Integer) As Long
MakeLong = (nHiWord * &H10000) Or (nLoWord And &HFFFF&)
End Function
|
|
|
|
Post by larrybtoys on Aug 21, 2023 12:18:45 GMT 1
The biggest problem I have with the lack of sprites with GB32 is animation. When you are moving several objects around the screen where the background is not a simple solid color you need to GET the background screen under the object prior to PUTTING the object there so that when you move the object away you can replace the background. This is fine (although a bit slow) when there are not multiple object overlapping. Is there a way for me to store the background screen elsewhere in order to always have the original image to restore. View my example:
Get (Stored Background) 100,100,150,150,Original_Image$
Put 100,100,SPRITE$(1),SRCAND
Put 100,100,SPRITE$(2),SRCPAINT
Put 100,100,Original_Image$
Get (Stored Background) 101,101,151,151,Original_Image$
Put 101,101,SPRITE$(1),SRCAND
Put 101,101,SPRITE$(2),SRCPAINT
And so on...
|
|
|
|
Post by Roger Cabo on Aug 21, 2023 17:42:36 GMT 1
From the method you've described using GET and PUT in GB32, I see a infinity significant challenge when it comes to animating multiple objects on a non-uniform background, especially with overlapping put and get.
To be frank, while the method you've chosen might work for a few objects, it becomes practically infeasible and extremely complex when dealing with a larger number, like 10 sprites that all congregate and move around the same spot. Storing and restoring segments of the background for each moving object individually can result in conflicts, missed restorations, and would be a nightmare to coordinate accurately.
Hardware sprites didn't restoring anything! They are overlaying like transparent clear film on a TV screen.
I strongly believe that an approach where the entire background is redrawn, followed by redrawing all visible sprites/objects in their updated positions for each frame, will not only simplify the process but also be more efficient in handling many objects. With today's computing capabilities, redrawing the entire screen can be accomplished quickly, avoiding the aforementioned complexities.
Here's a refresher on the suggested approach:
Dim t#, frames%
Do
t = Timer
// ... Freeze the screen before you draw..
// ... SendMessage() I can provide you with a function
Draw Background, 0, 0, Screen.x, Screen.y // Get, BitBlt. Anything you like
// ... Draw the visible sprites only and Everything
// ... is on top of the scene and any structures as well.
For i = 0 to all_Sprites%
If Sprite(i) is completely within screen.x.y.w.h
Draw Sprite(i) at x, y // No matter if the sprite moves or not.. Draw it.
Endif
Next
// ... Move any sprite anywhere as needed
// ... Make the screen visible // SendMessage() I can provide you with a function
Print AT(1, 1); frames%
While Timer - t < 0.033 // wait 33ms = ~30FPS
Sleep(1)
Wend
frames%++
DoEvents
Loop
Nothing more is required to draw anything you like.
And the great thing is, the player and objects can collide with anything you want..
For sure with some small additional work
|
|
|
|
Post by larrybtoys on Aug 22, 2023 0:38:27 GMT 1
I will play with this over the weekend. I would really like to see something like STOS that was developed for game design using sprites back in the day for the Atari ST. Or quite frankly any add-on program allowing multiple sprites for GB32.
|
|
and you can do exactly the same.
