_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Off Topic -> AGAWFrame |
|
| Fri, 20 Apr 2018, 14:01 | |
Jayenkai
|
I'm going to have to put a limit on spritesheet sizes, I think. 192x192 pixels seems to be the biggest that lodepng can cope with. If I make my own spritesheet in memory, I can seemingly get up to 512x512 before it fucks up, but lodepng struggles. I think it might be something to do with the actual decompressing of the png, rather than the overall size, but I'm not 100% sure. Anyhoo, current Flappyness! View on YouTube -=-=- ''Load, Next List!'' 
|
| Fri, 20 Apr 2018, 23:03 | |
Dabz
|
Canny!  Dabz
|
| Sun, 22 Apr 2018, 07:25 | |
|
Jayenkai
|
Trying to load audio again, this morning, and am noticing a rather odd thing. It seems that it fails if the audio I try to load is larger than a certain number of bytes.. More specifically it seems to be happening when I Malloc certain high numbers. Like, the memory is definitely there, as I can Malloc a high number a hundred times and it's fine.. but if I do a single Malloc of too high a number, that’s when it all fucks up.. It "feels" as if the 3DS has somehow segmented the memory into chunks, and if I try to Malloc over that single chunk limit, that’s when it fucks up. Further investigation is, of course, required.. but .. assuming I can figure out how to actually PLAY the audio data, it looks like I might be getting sound going, soon!! -=-=- ''Load, Next List!''
|
| Sun, 22 Apr 2018, 17:18 | |
Dabz
|
Sorta like a page frame overflow? I have no other means to describe it really, but depending how memory is mapped, could you malloc odds and sods and that will keep it confined, but going big big overflows the frame limit? Do I even know what I'm on about? What year is this? Who's the President? Memory can be weird... Just look at how the CPC draw's its shite from &C000 to &FFFF, that was heart breaking when you first tried displaying sprites! Dabz -=-=- Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
|
| Mon, 23 Apr 2018, 08:56 | |
|
Jayenkai
|
Boy, I tell ya.. Trying to get Audio working is being a complete arse!!!
-=-=- ''Load, Next List!''
|
| Tue, 24 Apr 2018, 06:50 | |
|
Jayenkai
|
 Ignoring Audio for today, I’ve decided to tackle the screens, instead. The top screen's "3D" has been activated, and it does indeed work.. .. after fucking hours trying to figure out why it wasn’t working. Turns out it was the same issues which was causing my earlier "moves all the co-ords" thing with the sprites. That was also happening when I would attempt the "other eye" and also the bottom screen. So, lots more complex maths are in the Framework, and I’ll need to stress test it all. Currently only the lines are being drawn in 3D. I need to add depth parameters to all my sprite routines. But.. yeah.. it's working!! The bottom screen methodology is also being figured out, and should be more-or-less a doddle to get to work. But first, stress testing, because I’m not sure it'll manage to keep up with everything I’m throwing at it. -=-=- ''Load, Next List!''
|
| Tue, 24 Apr 2018, 09:37 | |
|
Jayenkai
|
Flappadiddle-Doo seems perfectly fine with 3D mode on, drawing essentially 3 screens worth of objects. (Left eye, Right eye, Bottom screen) That is to say.. 1) 3D Mode is piss easy to implement, in my framework. Game.SetDepth(depth); the same as you would Game.SetAlpha(alpha); Game.SetRot(angle); and Game.SetCol(r,g,b); Rects, Lines, Text, Circles, Sprites, etc.. They all obey the Depth! 2) I just played Flappadiddle Doo with 3D mode switched on!! 3) OH MY GOD!!!!  I really, really need to get the audio working, now. Note : The bottom screen is currently a duplicate of the top screen. Work will soon begin on moving the menu and scores down there. -=-=- ''Load, Next List!''
|
| Tue, 24 Apr 2018, 11:58 | |
rockford
|
|
| Tue, 24 Apr 2018, 14:19 | |
shroom_monk
|
It's possible that the memory issue you're describing is due to memory fragmentation, Jay. When you malloc X bytes of memory, the system needs to find you a single, solid, unbroken X bytes of memory that is free. But it might not be able to find such an unbroken range, depending what else has already been allocated, even if the sum total of free space exceeds what you're asking for. For example (making up some numbers), say you have 1GB of RAM total, and you allocate six 100MB chunks of memory. What might sensibly happen is that these all get allocated one after the other, with 400MB of free space at the end. Then you delete the second and fourth chunks, leaving some 100MB gaps. The largest free chunk of memory is the 400MB at the end, but there's 600MB free overall. But if you try to malloc 500MB, it will fail, because there's no unbroken 500MB to put it in. That's a contrived example, of course, but you can probably imagine that the longer your game goes on running for, allocating and deallocating, the more fragmented your memory might become! Big game engines often implement their own memory management system to get around this, where they land-grab a massive chunk (gigabytes) of memory as soon as they start when they can be fairly certain they'll get it, and then organise how that memory is allocated manually, to ensure it meets their requirements. Not that I'm suggesting that's a worthwhile use of your time for your framework. There are other possibilities for what your problem is, of course (like what Dabz was mentioning earlier) - I don't really know anything about how the 3DS does its memory allocation. Just throwing this one into the mix as something to be aware of.
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Tue, 24 Apr 2018, 14:29 | |
|
Jayenkai
|
If it is fragmentation it's certainly not MY fragmentation!! This is during load, so I've not loaded/freed/etc things. They're literally only just loading for the first time! I'm thinking it's either just part of the way the 3DS's memory is set up or possibly something to do with the whole "You have to hack the 3DS with the homebrew launcher to get it running in the first place" thing. .. Could be either. I'm managing to work around it, now that I know exactly what's causing the many (MANY!) issues I was having. It's certainly going to be interesting designing games that run well on both a 400x240 display, and a 1920x1080 one, without requiring god-awful unrecognisable art assets! fwiw, one of my biggest arrays (Grid[]) has had to be shrunk down to 64Kb, the audio file limit also seems to be about 64Kb, and when loading images that seems to crap out at around the same size, too. So I'm definitely thinking it's probably an internal memory block size, or something. -=-=- ''Load, Next List!''
|
| Fri, 27 Apr 2018, 09:31 | |
|
Jayenkai
|
The past week or so, I've been working with the following (approximate) code. 1. csndinit() to initialise the audio doohickey. 2. Load wave into buffer. 3. Switch to next audio channel (0-7) 4. Stop current audio in channel, if any. 5. csndPlaySound.. Play audio from buffer, into selected channel. And it just hasn't been working, at all, no matter how hard I try. I tried loading in different methods. I tried using alt-buffers inbetween plays. I tried so much debugging information to ensure the audio's still in memory when I go to play it, that you'd swear I was slowly going crazy. Today, I found the problem. .... Audio channels start at 8.. Every single fucking time that I'd been trying to play audio on channels 0-7, it was silent, because it didn't know wtf I was trying to do. Gee, thanks for THAT error message, guys!! *sigh* OK, basic audio's finally bloody well working. Next challenge.. OGG Streaming. -=-=- ''Load, Next List!''
|
| Fri, 27 Apr 2018, 15:16 | |
|
Jayenkai
|
View on YouTube Damn.. game's crashing when trying to stream the ogg. Have gone back to just doing plain wav files for now, and I guess I’ll be ogging again, tomorrow! -=-=- ''Load, Next List!''
|
| Wed, 02 May 2018, 18:03 | |
|
Jayenkai
|
View on YouTube yaaargh!!!!! -=-=- ''Load, Next List!''
|
| Thu, 03 May 2018, 12:52 | |
|
Jayenkai
|
Micro Clampett is now available for download for the 3DS! Woot! Downloady page -=-=- ''Load, Next List!''
|
| Sat, 05 May 2018, 11:04 | |
|
Jayenkai
|
On a Space Shooting Trail is now on a 3DS Homebrewing Trail!! Downloady page! To9k a fair amount of memory management to get this one going, as I’d previously set up a giant "lines" array to draw all the extra polys. Had to strip that out from the 3DS edition, but the game doesn’t seem too bad without them. -=-=- ''Load, Next List!''
|
| Mon, 07 May 2018, 04:37 | |
|
Jayenkai
|
Flappadiddle-Doo 3DS Progress Flappadiddle now.. "works" on 3DS. But the graphics have all been shrunken down to 4 times their size, and the pixels are all a bit of a mess, so I need to re-art a whole lot of the game. I WAS hoping to release it, today, but it's such a lovely day outside that I don't think I'll be sitting faffing about with pixels all day! -=-=- ''Load, Next List!''
|
| Mon, 07 May 2018, 06:04 | |
|
Jayenkai
|
Fuck going outside, Flappadiddle-doo needs Flappadiddle-doing!!! Flappadiddle Doo is now available on 3DS Homebrew -=-=- ''Load, Next List!''
|
| Mon, 07 May 2018, 16:18 | |
cyangames
|
Now I have a good reason to grab a 3DS XD
|
| Mon, 07 May 2018, 16:34 | |
|
Jayenkai
|
Probably not recommended just for my games! But, sure, why not
-=-=- ''Load, Next List!''
|
| Sun, 13 May 2018, 06:37 | |
|
Jayenkai
|
Hmm.. Memory issues again. CreateBuffer(1024,1024) is SERIOUSLY breaking on the 3DS. Usually I scale all images down to 1/4 size, but if I do that to a draw buffer, it means all buffer-drawing will have to similarly be 1/4 scale, which means odd maths when drawing to the buffer, and things won't look anywhere near as "clean" as they do normally. Not really sure what the best method for doing this might be. -=-=- ''Load, Next List!''
|
| Sun, 13 May 2018, 10:21 | |
|
shroom_monk
|
Are you able to use a number of smaller buffers to represent the data of the one big one? e.g. four 512x512 buffers, or sixteen 256x256 ones. Still needs a bit of maths fiddling to get it right (though translation is arguably simpler than scaling) and you'd have to draw to several buffers when on the boundaries between them, but at least then you don't lose any resolution?
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Sun, 13 May 2018, 10:39 | |
|
Jayenkai
|
Nah, tried that. Still hit the same memory block. Poor little 3DS Original (not New) only has 6 measly megabytes of VRAM. Add in the game logo, particle sprites, bitmap font image, and the actual game's sprites.. soon adds up. -=-=- ''Load, Next List!''
|
| Sun, 13 May 2018, 12:40 | |
|
shroom_monk
|
Ah, curses. I guess something's going to have to get smaller then, yeah. :/ Any chance you're able to drop the colour depth down, so that each pixel requires less space?
-=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Sun, 13 May 2018, 13:07 | |
|
Jayenkai
|
Not a clue! I think (*!) that the DevKitPro stuff automagically ups everything back to RGBA32 when transferring it to VRam. Maybe..!? I dunno, I'm bluffing my way through this, if I'm honest!! Either way, it's probably better for me to just plain draw the tilemap per-frame with sprites. That way, I KNOW I can realtime switch tiles if need be (eg door animations). Otherwise, I'd probably have to do "draw to buffer, wait a frame, draw buffer to screen" for it to show up. I was hoping to have realtime blood-splodges in a new Alien Deathmatch, but that plan's not going to happen if I can't do nice big rendered bitmap tilemaps.. But it also would've limited the size of the maps, and there's all manner of other complexities on top of just the tilemap.. Bah, humbug! -=-=- ''Load, Next List!''
|
| Mon, 14 May 2018, 07:25 | |
rockford
|
What happens if you unload/delete images from memory after use? You don't need logos etc. once displayed, so unload them. Don't keep everything in memory.
|
| Mon, 14 May 2018, 08:05 | |
|
Jayenkai
|
Sure I do!!! Well, ok, maybe not.. But it's nice to have it there! Fills a bit of the blank space on the lower screen, for starters. But basically I'm having a limit of 256x256 MAX, whether there's oodles of other stuff in memory or not, the 3DS (and/or my code) seems to refuse having anything larger. Maybe that's an actual physical texture limit, or maybe it just is the shitty way I'm loading them.. But everything I've tried so far seems to max out at 256x256. So, that's a roadblock straight away. The screen's 400x240, so you're going to have at least 2 of those buffers onscreen at once. And I'd assume you'd need 4, since there would be many instances where the vertical would need to have 2 showing, too. I'm also assuming (although I haven't yet gotten to the point of testing this, but .. Android does it!! I've learned not to chance it..) that the moment between saying "Move this to the VRam" and "Draw it on the screen" will probably need at least a single frame's gap. Realtime "Draw a blood splatter onto the buffer" would REALLY not be something that's doable, under those circumstances. That was the main reason I wanted to get it working. Without it, I can use fading bloodsplat particles, and an old fashioned sprite based tilemap. The engine should run pretty smoothly, especially since it's running on such a low resolution. Smaller buffers will still be usable for static backgrounds and the like, but they'll end up at a much lower resolution than the Windows version.. The Win edition is "Bigger than virtual screen" (1024x1024 against a typical 800x600), whilst the 3DS's buffer will be "Smaller than screen" (256x256 vs 400x240 screen) I might double it up horizontally, but again that's memory dependent, and also brings all manner of scaling issues into play, too. It's not ideal.. I'm wondering if it might be possible to access DS-style "Tilemap Layer" elements, alongside the 3D "GL-like" things that I'm currently doing.. And if so, how well I might be able to merge the two, and also get the Framework to manage the two different styles. ... But for now, I'm just going to ignore the whole bloomin' thing, and move on to the more important stuff. I can work around having missing graphical features. I have done in the past! Flappadiddle-Doo is completely missing it's level backgrounds, and it doesn't ever feel like they're missing. -=-=- ''Load, Next List!''
|
|
|
| |||
|
| ||||