I'm really excited for this series, it's a tech stack I really want to use and your videos are very clear. Thank you so much for making it, I'm excited to see more : )
This series is great so far, looking forward to more! I have been using Love2d, but I would much rather be writing a compiled language so once I learn some Go core concepts, I am gonna start working my way through this.
I'm enjoying watching this series so far. I'm excited to see where it goes. I have one question though. When you are getting a subimage with the rectangle, you used the top left as 0, 0 and the bottom right as 16, 16. If the sprites are each 16 by 16, wouldn't you want to use 15, 15 for the bottom right? I wuld think you would be getting anextra pixel with the way you're doing it unless the bottom right value is exclusive.
I haven't run into anything that makes me favor either yet structurally. However, the fact that ebitengine is written in pure go, and is easily runnable on web, makes me prefer it for Go development.
Interfaces are a tough topic at first, but they're really important for making Go apps. Think of it like a blueprint. For example, I know my phone can make calls and send texts, but I don't know everything that goes into the processes. Some manufacturers may implement them in different ways, but that doesn't matter to me the user. In Go, this could be a "Phone" interface, that has two functions "Call" and "Text". Any struct that creates methods for "Call" and "Text" is considered a phone, so we can treat it like one. It doesn't really matter what the struct does, as long as we can call those methods. I hope that helps ! If not, I can help more on my discord server :)
@@codingwithsphere So with interfaces, I can iterate over a vector or array with different objects but with similar functions? That is, all my objects have an update and a draw, I just iterate them and for all it would be the same?. I think that's how the ECS worked. It would be similar to all having a parent class and all their functions would be overridden? I think that's how I understand it (my first language was C++, so that's all I know).
@@meida_oficial Yes. If you have a base interface and you make a list of that interface, you can add any object that impliments those functions. So in our case, in future episodes we will create an interface that has a "Draw" function. Then, our player, enemies, and items will implement this draw function, so we can loop over the list and draw them all
@@meida_oficialAn interface describes the methods a type has. You don’t need to extend from an interface in Go, it simply works as long as all the function signatures of the methods are the same and the methods are pointer receivers. So if you declare an interface with say a method walk(), then any type that has the same method will be accepted as the interface you declared. The type assertions can then help you get the actual type, which may have some additional functionality. One thing that is useful (and should definitely be checked) is that the type assertion actually works. A safe way to do this would be: img, ok := image.(*ebiten.Image) if !ok { // assertion failed, handle } Definitely different if you’re used to C++ like inheritance, but very powerful once you understand how interfaces work.
@@codingwithsphere I wrote up a much larger comment about types and interfaces, but TH-cam swallowed it for some reason. Here in short form: - A type can be used as an interface if the type implements the methods of said interface - The types do not need to extend an interface, it simply works (compiler will complain if the type does not match the interface) - A trick to ensure that a type implements an interface is to do this: type A interface { B() } type Impl struct {} var _ A = Impl{} This code will not compile since the Impl struct does not implement the method declared in the interface - Type assertions actually return two values - this gives you a chance to react if the underlying type is not what you expect eImg, ok := img.(*ebiten.Image) if !ok { // type assertion did not work, handle } Hope this helps!
I'm really excited for this series, it's a tech stack I really want to use and your videos are very clear. Thank you so much for making it, I'm excited to see more : )
i don't even think i will program 2D game in GO, but ur content is so awesome that catch me, keep up the great stuff man.
thanks!
This series is great so far, looking forward to more! I have been using Love2d, but I would much rather be writing a compiled language so once I learn some Go core concepts, I am gonna start working my way through this.
I think you'll love it! go is a great and surprisingly simple language. it is really fun to code in it!
I'm loving this series, it's just what I was looking for!!
this is so great ❤
I just found this channel and I hope 8th episode won't be the last one :) You have talent to knowledge sharing.
awesome content, keep it up
I might be blind but the asset pack is not in the description
I'm enjoying watching this series so far. I'm excited to see where it goes. I have one question though. When you are getting a subimage with the rectangle, you used the top left as 0, 0 and the bottom right as 16, 16. If the sprites are each 16 by 16, wouldn't you want to use 15, 15 for the bottom right? I wuld think you would be getting anextra pixel with the way you're doing it unless the bottom right value is exclusive.
The second coordinate is exclusive. It's a little weird haha
Great series, but for some reason the TH-cam playlist isn't in order.
how you like ebiden compared to raylib?
I haven't run into anything that makes me favor either yet structurally. However, the fact that ebitengine is written in pure go, and is easily runnable on web, makes me prefer it for Go development.
@codingwithsphere it's also easier to build for multiple platforms without facing trouble with cgo
I think you forgot to add the link to the asset pack... i found it though. Greate series, waiting for more.
You lost me a little bit with the interface topic, but thank you anyway
Interfaces are a tough topic at first, but they're really important for making Go apps. Think of it like a blueprint. For example, I know my phone can make calls and send texts, but I don't know everything that goes into the processes. Some manufacturers may implement them in different ways, but that doesn't matter to me the user. In Go, this could be a "Phone" interface, that has two functions "Call" and "Text". Any struct that creates methods for "Call" and "Text" is considered a phone, so we can treat it like one. It doesn't really matter what the struct does, as long as we can call those methods. I hope that helps ! If not, I can help more on my discord server :)
@@codingwithsphere So with interfaces, I can iterate over a vector or array with different objects but with similar functions? That is, all my objects have an update and a draw, I just iterate them and for all it would be the same?. I think that's how the ECS worked. It would be similar to all having a parent class and all their functions would be overridden? I think that's how I understand it (my first language was C++, so that's all I know).
@@meida_oficial Yes. If you have a base interface and you make a list of that interface, you can add any object that impliments those functions. So in our case, in future episodes we will create an interface that has a "Draw" function. Then, our player, enemies, and items will implement this draw function, so we can loop over the list and draw them all
@@meida_oficialAn interface describes the methods a type has. You don’t need to extend from an interface in Go, it simply works as long as all the function signatures of the methods are the same and the methods are pointer receivers.
So if you declare an interface with say a method walk(), then any type that has the same method will be accepted as the interface you declared. The type assertions can then help you get the actual type, which may have some additional functionality.
One thing that is useful (and should definitely be checked) is that the type assertion actually works. A safe way to do this would be:
img, ok := image.(*ebiten.Image)
if !ok {
// assertion failed, handle
}
Definitely different if you’re used to C++ like inheritance, but very powerful once you understand how interfaces work.
@@codingwithsphere I wrote up a much larger comment about types and interfaces, but TH-cam swallowed it for some reason. Here in short form:
- A type can be used as an interface if the type implements the methods of said interface
- The types do not need to extend an interface, it simply works (compiler will complain if the type does not match the interface)
- A trick to ensure that a type implements an interface is to do this:
type A interface {
B()
}
type Impl struct {}
var _ A = Impl{}
This code will not compile since the Impl struct does not implement the method declared in the interface
- Type assertions actually return two values - this gives you a chance to react if the underlying type is not what you expect
eImg, ok := img.(*ebiten.Image)
if !ok {
// type assertion did not work, handle
}
Hope this helps!